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[57] ABSTRACT 

A design control system suitable for use in connection with 
the design of integrated circuits and other elements of 
manufacture having many parts which need to be developed 
in a concurrent engineering environment with inputs pro- 
vided by users and or systems which may be located 
anywhere in the world providing a set of control information 
for coordinating movement of the design information 
through development and to release while providing 
dynamic tracking of the status of elements of the bills of 
materials in an integrated and coordinated activity control 
system utilizing a repository which can be implemented in 
the form of a database (relational, object oriented, etc.) or 
using a flat file system. Once a model is created and/or 
identified by control information design libraries hold the 
actual pieces of the design under control of the system 
without limit to the number of libraries, and providing for 
tracking and hierarchical designs which are allowed to 
traverse through multiple libraries. Data Managers become 
part of the design team, and libraries are programmable to 
meet the needs of the design group they service. 

26 Claims, 26 Drawing Sheets 
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FIELD OF THE INVENTION 

This invention is related to a Data Management Control 
System and Methods for Computerized Design Automation 
(CDA) Applications, and particularly to methods useful for 
concurrent engineering in connection with the design, devel- 
opment and manufacturing of complex electronic machines 
such as computer systems and their complex electronic 
parts. 

GLOSSARY OF TERMS 

While dictionary meanings are also implied by certain 
terms used here, the following glossary of some terms may 
be useful. 

AFS Andrew File System — File Management System 
developed by Transarc Ioc. and used on Unix/AIX 
Networks. 

API Application Program(ming) Interface. 

ASC Accredited Standards Committee (ANSI) 

BOM Bill of Materials 

CIM Computer Integrated Manufacturing 

CR Control Repository 

CRC Cyclic Redundancy Check 

CLSI Compiler VHDL Analyzer developed by Compass 
Design Systems 

DCS Design Control System. Our Design Control System 
incorporates Data Management System Processes, 
including interactive data management systems which 
supply processes which may be applicable in general 
data management systems, such as a process manager, 
a promotion manager, a lock manager, a release 
manager, and aggregation manager and the other pro- 
cesses we describe herein as part of a Computer Inte- 
grated Design Control System and, where the context 
applies, Data Management System, is a Data Manage- 
ment System functioning within an overall integrated 
design control system. 

DILP Designer Initiated Library Process 

DM Data Manager or Data Management 

DMCU Data Management Control Utilities 

DMS Data Management System 

DR Data Repository 

EC Engineering Change 

EDA Electronic Design Automation 
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GUI Graphical User Interface 

PDM Product Data Management 

P1M Product Information Management 

PN Part Number 

RAS Random Access Storage 

sim static inline memory 

tape-out Delivery of a coherent set of design data to 
manufacturing. Also known as Release Internal Tape 
10 (RLT) within IBM. 

TDM the Cadence Team Design Manager (most currently 
Version 4.4) 

VHDL Very High-level Design Language — A high level 
15 language comprised of standards supported by IEEE 
and the EDA industry. The language is widely used in 
the electronics and computer industry and by the mili- 

. tary as an alternative to Verilog and ADA, other high . 
level computer coding languages. 

20 BACKGROUND OF THE INVENTION 

As Data Management systems grow more complex, they 
have more users interacting with them, and issues such as 
performance, data integrity, workload management, batch 

25 processing, efficiency and continuous availability need to be 
solved. Many systems on the market today can only handle 
small numbers of users simultaneously, offer little or no 
expansion capabilities and frequently require manual inter- 
vention to process data through the system. In addition, the 

3Q mechanisms for maintaining data integrity, ownership, and 
file management are either limited in capability or are unable 
to prevent loss of data and/or collisions under certain 
conditions. With the growing presence of distributed 
computing, and the increased need for sharing large amounts 

35 of data across an enterprise, a solution is required to address 
these problems for a computer integrated design control 
system for concurrent engineering and other applications. 

In the article entitled "Beyond EDA (electronic design 
automation)", an example of one kind of computerized 

40 design automation (CDA), published in Electronic Business 
Vbl.19, No.6 June 1993 P42-46, 48, it was noted that while 
billions of dollars have been spent over the past (then and 
still last) five years for electronic design automation systems 
(EDA) and software to help companies cut their design 

45 cycle, a huge gulf remains between design and manufactur- 
ing. To eliminate the gulf and thus truly comply with the 
commandments, companies are extending the concept of 
concurrent engineering to enterprise wide computing. The 
concept, which calls for integrating all the disciplines from 

50 design to manufacturing is becoming the business model of 
the 1990fe. Achieving an enterprise wide vision requires 
tying together existing systems and programs and managing 
the data that flows among them. Software that makes that 
linkage possible is largely in the class known by two names: 

55 product data management (PDM) or product information 
management (PIM). Mr. Robinson, the author, described the 
experiences of several companies with PIM and PDM, in 
particular Sherpa and Cadence. 

The design of complex parts, such as integrated circuits, 

60 computers, or other complex machines in a complete manu- 
facturing operation like IBM's requires computer capability, 
with computers capable of processing multiple tasks, and 
allowing concurrent data access by multiple users. The IBM 
System 390 operating system known as Multiple Virtual 

65 Storage (MVS) allows such things as relational database 
management methods, such as the TIME system described 
by U.S. Pat. No. 5333,316, to be used to reduce design time. 
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The TIME system is used within IBM for the purposes 
described in the patent during circuit design. However, these 
prior efforts treated design as directed to an entity and did 
not achieve the efficiencies provided by the system detailed 
in our description of our invention, which also can run under 
MVS, but also under other operating systems. Our detailed 
description of our invention will illustrate that we have 
furthered the objects of the invention of U.S. Pat. No. 
5,333,316 by increasing the flexibility of a number of circuit 
designers who may concurrently work on designing the 
same integrated circuit chip and reducing the interference 
between chip designers. With the prior system, a user (a 
person, processor or program capable of using data in a 
relational database) was given a private copy of the master 
table. Alteration of a row in the user table was not auto- 
matically updated in the master table, because a lock mecha- 
nism prevented the row update, but that was an great 
improvement at the time, because no longer did multiple 
users have to wait for copying of a table, each time data from 
a user needed to be updated. This row locking and treatment 
of data has become widespread in the relational database 
field, and it has been enabled for use with multiple instances 
of a platform even on Unix machines today. We should note 
that also in the MVS art, there have been proposed various 
library systems, e.g. those represented by U.S. Pat. Nos. 
5333312 and 5333,315 and others which relate to IBM's 
Image Object Distribution Manager in the ImagePlus prod- 
uct line of IBM, and IBM's Office Vision are examples of 
systems enabling control of a source document while allow- 
ing access by multiple users. Implementation of these pat- 
ented ideas enable synchronous and asynchronous copying 
of a document into a folder in a target library. These methods 
provide for check out of a document and its placement in a 
target library while locking the document in the source 
library to preveot changes while the checked out document 
is out. But these steps are only some of the many things that 
are needed to bring a product to a release state. Bringing a 
product to a release state is an object of the current devel- 
opments relating to design control in a manufacturing set- 
ting. 

Concurrent engineering is required among many engi- 
neers working in parallel and at different locations world- 
wide. Furthermore, as noted by Oliver Tegel in "Integrating 
human knowledge into the product development process" as 
published in the Proceedings of the ASME Database 
Symposium, Engineering Data Management: Integrating the 
Engineering Enterprise ASME Database Symposium 1994. 
ASCE, New York, N.Y., USA. p 93-100, specialists who are 
not working directly together are often needed for solving 
the demanding tasks that arise during the development of 
today's advanced products. During product development, 
assistance is required from other departments such as 
manufacturing, operations scheduling, etc. Even the vendors 
and customers should be integrated into the product devel- 
opment process to guarantee the product developed will be 
accepted in the market. 

There is a need for integrators/coordinators/model build- 
ers and the designers to work together to create a next 
release. Information from different people in different forms 
must be collected aiming at a final good design. A problem 
occurring during product development is, how to know 
which people to contact for what kind of information, but 
that is only one. During all of the process concurrent 
engineering, particularly for the needs of complex very large 
scaled integrated system design, needs to keep everything in 
order and on track, while allowing people to work on many 
different aspects of the project at the same time with 
differing authorizations of control from anywhere at any- 
time. 



4 

For the purpose of the following discussion, need to say 
that we call our system a "Computer Integrated Design 
Control System and Method" because it encompasses the 
ability to integrate CIM, EDA, PDM and PIM and because 

5 it has the modularity making it possible to fulfill these needs 
in a concurrent engineering environment particularly useful 
to the design of complex very large scaled integrated sys- 
tems as employed in a computer system itself. The making 
of these systems is a worldwide task requiring the work of 

10 many engineers, whether they be employed by the manu- 
facturer or by a vendor, working in parallel on many 
complete parts or circuits which are sub-parts of these parts. 
So as part of our development, we reviewed the situation and 
found that no-one that we have found is able to approach the 

15 creation of "Computer Integrated Design Control System" 
like ours or employ the methods needed for our environ- 
ment. Our methods are modular and fulfill specific 
functions, and yet make it possible to integrate them within- 
a complete "Computer Integrated Design Control System". 

20 A patent literature review, especially one done with ret- 
rospective hindsight after understanding our own system and 
method of using our "Computer Integrated Design Control 
System" will show, among certainly others, aspects of DMS 
systems which somewhat approach some aspect of our own 

25 design, but are lacking in important respects. For instance, 
after review of our detailed description, one will come to 
appreciate that in modern data processing systems the need 
often arises (as we provide) to aggregate disparate data 
objects into a cohesive collection. These data objects may 

30 reside at various levels of completion, spanning multiple 
versions and/or repositories in a hierarchical, multi-tiered 
data management system. Additionally, these data aggrega- 
tions may need to be hierarchical themselves, in order to 
enable the creation of large groupings of data with varying 

35 levels of granularity for the data included therein. In such a 
data management system, the end-users of the data aggre- 
gates are not necessarily the "owners" of all or any of the 
data objects comprising the data aggregate, but they have a 
need to manage the particular collection. Management of a 

40 data aggregation may include creating the aggregation, 
adding or deleting data objects, moving the aggregation 
through a hierarchical, multi-tiered data management system 
and tracking the status of the data aggregation in real-time 
while maintaining the coherence of the data aggregation. 

45 Creation of a data aggregation or the addition of a data 
object to an existing data aggregate may need to be accom- 
plished within the data management system or via data 
objects imported into the data management system through 
application program interfaces for the data management 

50 system. 

With such a focus, when one reviews the art, one will 
certainly find, currently, data management systems which 
provide means for grouping components of a data system to 
facilitate the retrieval thereof. However, these data manage- 
55 ment systems are insufficient and lacking because they fail 
to address the above-referenced need for grouping disparate 
data items, just to mention one aspect of our own develop- 
ments. 

Another example, U.S. Pat. No. 5,201,047 to Maki et al. 

60 (issued Apr. 6, 1993) teaches an attribute based classification 
and retrieval system wherein it is unnecessary to implement 
an artificial code for indexing classifications. The patent 
teaches a method for defining unique, user-determined 
attributes for storing data which are capable of being readily 

65 augmented without necessitating the modification of the 
underlying query used for retrieval thereof. However, the 
Maki et al. patent requires that the data items being grouped 
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share at least one common attribute to enable tbe grouping, pieces of disparate systems which don't interact, and even 
and therefore fails to address the problems of managing data such a combination would not achieve our desirable results, 
aggregates formed from disparate and unrelated data For the purposes of comparison, after our own description 
objects of our environment, our "Computer Integrated Design Con- 
Other data management systems address the creation of 3 H? 1 S y* l ™"< K we "® discuss tb « °f the ?^ a(x 
data aggregates coupled to particular processes implemented Team Design Manager Version 4.4 and VfewLogic s View- 
in tbe data system. For example, U.S. Pat. No. 5,321,605 to Data » *ctK« which compare with and refer to the 
Chapman et al. (issued Jun. 14, 1994) teaches tbe creation of Sections of our own preferred Computer Integrated Design 
a Bill of Resources table which represents the resources Co° ,rol 45 861 forth a < tbe be 8 ,nnm 8 of « **** 
consumed in the performance of a given process. Attribute 10 description of our invention. This comparison will show the 
tables for the given resources are utilized to determine shortcomings^ these prior systems, as well as some 
whether an additional processes which will consume some changes which could be made to these pnor systems to allow 
or all of the resources of a given process can be initiated. Tbe ^m to ™P m " performance in our concurrent engineering 
paten, to Chapman et al., requires that each process to be environment by takmg advantage of aspects of our own 
initiated have a particular Bill of Resources aggregate asso- « development as alternative embodiments of our invention, 
ciated therewith. This tighdy coupled construct does not Historically many attempts have been made to collect or 
permit the creation of data aggregates not related to a gro«P objects together in order to solve typical data man- 
particular process implemented in the data management agement problems. These problems may include identifyrog- 
system. Furthermore, since a process must be contemplated ^ of the files used to create a model, or grouping files 
in order to create a Bill of Resources table, Chapman et al. 20 together to facilitate transport through a medium The intent 
do not permit the creation of aggregates without foreknowl- * 10 ensure the group remains together for a speci- 
edge of the process that requires the resource. Thus, in a fied penod of time. 

manner similar to that described for Maki et al., Chapman et The most common method in use today is to create a 

al. require that a relationship between the elements exist listing of files commonly referred to as a Bill of Materials, 

prior to the formation of the Bill of Resources grouping. 25 Many commercial products permit creation of such a BOM, 

Also, unrelated DMS systems are known which are used ■*» these BOM are static list BOM. For example, is one of 

for hardware implementations which enable related data in ««* me mbers of tbe BOM disappears or gets changed, he 

a computer memory, storage or I/O subsystem to be physi- «s unaware that the original data set used to create the 

cally grouped in proximity to other such data so as to B0M f D0 longer valid. 

improve hardware performance, application performance, 30 We ^ve created a new process which we call an i Aggre- 

and/or to solve memory management issues are known. For g ation Manager which can be used in Bill of Materials 

example, U.S. Pat. No. 5,418,949 to Suzuki (issued May 23, applications but which overcomes pnor disadvantages and 

1995) teaches a file storage management system for a also one which can be used in our Computer Integrated 

databasewhicbachievesaliighlevelofclusteringonagiven Design Control System, 

page and teaches loading related data from a secondary 35 SUMMARY OF THE INVENTION 

storage unit at high speed. The patent uses map files includ- , Q accordaDCe ^ our ^trtion we provide a method for 

ing a metamap file for defining page to page relations of terized desfen automation , comprising, accessing a 

data. These hardware implementations are not related to the fi , e ^ d daUbase management system for mana ging a plu- 

present invention, as they involve tbe management of the ^ of jec(s M a ^ CODtrol organizing data 

physical contents of a data object rather than the manage- ^ £ each ^ for ^ reK)rds aaJ a comro , 

ment of aggregations of data objects as we perform the ^ a common access interface and one or 

methods of our present invention. It is contemplate^ mo Tdatabases, said control repository communicating with 

however, that such known hardware techniques may be ^ rf ^ desi ffl fof te of 

implemented m ^system comprising the aggregation man- and ^ da , a ^ tories of ^ data managemen t 

agement features disclosed herein, thereby further augment- ^ a ^ rf tK> each man . 

mg the overall system efficiency. agef fK ^ Bg a witbin this envi- 

During our development process we have viewed the ro nment we provide application support whereby users 

development of others. Even the best of the ED A (electronic combine selected ones of said managers for supporting an 

design automation) design bouses don't have an integrated so computerized design automation application environment 

approach like we have developed. suitable for multiple users of a user community located at 

For the purposes of this background, we will discuss some workstations anywhere in tbe world accessible via a 
of the various approaches already used specifically viewing network, an intranet, extranet or via the internet, 
them in light of our own separate developments which we Thus it will be seen that our invention relates to storing, 
will further elaborate in our detailed description of our 55 moving, retrieving and managing data in a system corn- 
invention which follows later in this specification. prised of one or more shared public libraries interacting with 

In the field of EDA, there are today two preeminent one or more private libraries arranged in a client server 
vendors of development software, Cadence Design Systems, environment. Elements of the system may exist on a homog- 
Inc. and ViewLogic, Inc. Of course there are others, but enous computer platform, or the elements may be scattered 
these two companies may have a greater range of capability 60 across multiple platforms in a heterogeneous environment, 
than the others. Also, there are in bouse systems, such as The Design Control System incorporates processes for hard- 
IBM's ProFrame which we think is unsuitable for use. It will ware design, software development, manufacturing, inven- 
not function well as a stand-alone DM point tool for inte- tory tracking, or any related field which necessitates execu- 
gration into a foreign framework But even tbe largest tion of repetitive tasks against multiple iterations of data in 
microelectronic systems are customers of the two named 65 a quality controlled environment and our invention enables 
vendors which we will compare. Today, a DCS, it will be sharing of libraries in this environment for concurrent engi- 
seen, without our invention, would require fitting together neering. 
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We provide with these appications various systems, meth- agement system and third party tools. Thus we further 

ods and processes for data management particularly suited provide that each component is labeled as an input or an 

for use with a data management system having shared output of its associated anchor. Thus we provide that each 

libraries for concurrent engineering from locations any- one component may be an anchor to another different model, 

where in the world, along with an management systems 5 and when such a component is an anchor to another different 

allowing promotion of multiple design BOMs through van- model, said different model consists of said said such 

ous levels of development, while handing multiple component acting as one anchor and further consisting of 

problems, multiple releases and multiple parts control for one or more associated components each of which is a data 

computer integrated design control within our data manage- object in said data management system. In accordance with 

ment system for releases, and file and database management. 10 our invention our components components can belong to 

Our invention provides a design control system usable in any level ^ version of any library in said data management 

a concurrent engineering process which can cooperate io a system and our components are not restricted to the same 

distributed environment worldwide to enable a design to be library, level and version as the anchor, and our components 

processed with many concurrent engineering people and can comprise multiple data types, including data generated 

processes. The system we employ uses a a data management 15 bv too ^ s of said data management system and third party 

control program tangibly embodying a program of instruc- took. 

lions executable by a supporting machine environment for ...Each of our components has field identifiers like those of 

performing method steps by an aggregation manager of a our anchor and each component is also labeled as an input 

data management system having a library organization or an output of its associated anchor. Each one component 

which receives a request of a user initiated from said 20 may be an anchor to still another different model, with each 

displaced client screen and fulfills the request by providing component being labeled as an input or output in relation to 

result via our data management system's aggregation man- its anchor file. All components of a model are either static 

ager. and thus does not move through said data management 

Our invention provides an improved way to make or system but is tracked by the system or dynamic and moves 

import a model, and provides a dynamic way to track the 25 through said data management system with its associated 

model during its course through its design phase. We provide model as part of an action of promoting a model when a 

a way to track the BOM model is promoted, a dynamic member being labeled as an 

In order to make a common model, we display for jfP* or f 0Ut P* «P«* to its a^ciated anchor, while 

creation of a model one or more control screen sections as m both arid ^ponents may be labeled as staUc. 

part of a control panel input screen allowing creation of a With these facilities, concurrent engineering is enhanced, 

model by interactive user activity, by importing a file listing, and after creation of a model, thereafter, our system provides 

by searching of a library of files in said data management continuously tracking the created model while allowing a 

system and importing a located file, or by use of an appli- user to modify it by adding components, deleting 

cation program interface with a collection of model man- components, changing the status or deleting said created 

agement utilities utilities. Our sections of said control screen model, and allowing promotion of a model in our data 

panel include: processing system through the libraries of our data process- 

(a) a display screen section displaying a first field rep re- m S svstcm - 

senting the name of an anchor name field of a model which This, along with many other changes have been made as 

is identical to the name of a data object which is serving as 40 detailed in the description of our invention which follows. 

a named anchor; BRIEF DESCRIPTION OF THE DRAWINGS 

(b) a display screen section displaying a second field 

representing a library where said named anchor resides; The subject matter which is regarded as the invention is 

(c) a display screen section displaying a third field rep- Particularly pomted out and distinctly claimed in the con- 
resenting the type of data object identified by said anchor « P 0 * 100 of the ^cabon. The invention, however, 

both as to orgarnzation and method of practice, together with 

. , . , „ , , further objects and advantages thereof, may best be under- 

(d) a display screen section .displaying a fourth field sUyod b tQ ^ foUowin description taken in 
representing user entries for the version of said named connection ^ me accompanying drawings in which: 

' . 50 FIG. 1 illustrates a prior art system in which our present 

(e) a display screen section displaying a fifth field repre- system can operate by made to tne database and 
senting user entries for the level of said named anchor for desi conlro , s ^ em> ^ accordance ^th our 

use by a user or a third party tool for creating, modifying or description. 

deleting an aggregate collection of data objects eDCompas- 2 iUustrates ouf ferred embodimeat > s ^ entry . 

ing those used for items that are identified, tabulated, cc ™„„ M1 , ^ . _ , „ J 

tracked, validated and invalidated, and promoted, as are bills 55 _ ™- 3 illustrates our preferred Design Control System 

of materials, by said data management system; and Structu re; 

(f) a display screen section displaying a sixth field rep- ^.J Pirates our P referrcd Desi S n System 
resenting user entries for the status of said named anchor. ^ Structurc ^ Versions; 

Our model thus consists of one anchor and one or more 60 j (filustrated in parts 5a and 5i>) illustrates our 

associated components, each of which is a data object in said P referrcd Desi S n Contro1 Scarch Exam P les; 

data management system. This means that our components ^ 6 mustrates our Preferred Mechanism for Update 

can belong to any level and version of any library in said Locks; 

data management system and said components are not FIG- 7 (illustrated in parts FIG. 7a and 7b) illustrates our 

restricted to the same library, level and version as the anchor, 65 preferred Promotion Mechanism; 

and our components can and do comprise multiple data FIG. 8 (illustrated in parts FIG. 8a and Sb) illustrates our 

types, including data generated by tools of said data man- preferred Design Fix Management and EC Control; 
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FIG. 9 illustrates our preferred DCS Using an Actor/ 
Object Environment; and 

FIG. 10 illustrates our preferred Example of Location 
Independent Data Tracking; 

FIGS. 11, VLa-Ud describes the QRFILDEL Process. 

FIG. 12 illustrates the overall diagram of the Promote 
Process. 

FIG. 13 depicts a data entry screen for initiating a 
Promote. 

FIGS. 14a thru 14f describes the algorithm for Promote 
Foreground Processing. 

FIG. 15a thru lSe describes the algorithm for Promote 
Background Processing. 

FIG. 16 illustrates the Overall Structure of our Design 
Control System's Data Management facilities. 

FIG. 17 illustrates the Control Repository. 

FIG. 18 illustrates the Data Repository. 

FIG. 19 illustrates the Inverted Tree Library Structure 

FIG. 20 illustrates the Library Structure File. 

DETAILED DESCRIPTION OF THE 
INVENTION 

Overview (Section 1.0) 

In order to introduce our Design Control System we will 
describe it as it can be applied to development of complex 
circuit design and development projects such as micropro- 
cessor design projects. The implementation of our Design 
Control System can be implemented in a variety of ways 
using many computing platforms as is suitable for a con- 
current engineering project While we will describe our 
preferred embodiment, it should be recognized that with this 
teaching all or part of our exact implementation of user 
interfaces, methods, features, properties, characteristics and 
attributes may vary depending on the platform chosen and 
the surrounding design system. All of these variances will 
nevertheless employ those routines which implement our 
processes and which meet our requirements. 

Platform (Section 1.1) 

The Design Control System (DCS) in our preferred 
embodiment, even though it can be implemented with other 
platforms, runs on a network of RS/6000's (workstation 
class "personal" computers) with an AIX operating system 
arranged in a Client-Server fashion. Each client and server 
in our preferred embodiment, is able to implement cross 
platform code via interpretation, and thus can implement 
programs written in cross platform languages like Java and 
VRML. In such situations, Java can interact with VRML by 
describing extension modes, acting as scripts, and describing 
the actions and interactions of VRML objects. 

While more powerful situations are contemplated, the 
system can be installed in a prior art system, like that 
described in U.S. Pat No. 5333,312. Thus, as we show in 
FIG. 1, the prior art system of the earlier patent, can be 
employed in this application, by providing the system with 
new programs. However, such a system, as illustrated by 
FIG. 1 will be a data processing system 8, which may 
include a plurality of networks, such as Local Area Net- 
works (LAN), 10 and 32, each of which preferably includes 
a plurality of individual computers 12 and 30 (which may be 
RS/6000 workstations or powerful PCs such as the IBM 
Aptiva's. As common in such data processing systems, each 
computer may be coupled to a storage device 14 and/or a 
printer/output device 16. One or more such storage devices 
14 may be utilized, to store applications or resource objects 
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which may be periodically accessed by a user within the data 
processing system 8. As we have said the system is provides 
with a repository, illustrated by main frame/server computer 
18, which may be coupled to the Local Area Network 10 by 

5 means of communications links 22, and also to storage 
devices 20 which serve as remote storage for the LAN 10. 
Similarly, the LAN 10 may be coupled via communications 
links 24 supporting TCP/IP through a subsystem control 
unit/communications controller 26 and communications link 
34 to a gateway server 28. Gateway server 28 is preferably 
an individual computer which serves to link the LAN 32 to 
LAN 10. The main system can be located anywhere in the 
world, and remotely from the various servers and clients 
coupled to it over communications links. The main system 
can accommodate hundreds of users making requests to the 

15 centralized repository (a large server 18, such as one of 
IBM's S/390 platforms or IBM's RISC System/6000 Scal- 
able POWERparallel Systems (SP) platform for design 
control information. (AIX, S/390, RS/6000, RISC System/' 
6000 and Scalable POWERparallel Systems are trademarks 

20 of International Business Machines Corporation, Armonk, 
N.Y.) 

Since this repository 18 (a large server and its associated 
storage) is critical to the entire design team, it has the ability 
to remain available if a single server fails. In addition, the 

25 data is secured via a backup or archiving mechanism per- 
formed on a regular basis. Our DCS has important perfor- 
mance characteristics. It can handle a distributed computing 
environment with data being transmitted over LANs and 
telephone lines linking distant locations in real time. Users 

30 at one site experience no noticeable delays accessing data 
physically located at another site. Due to the complexity of 
the design, maximum throughput is attained by transferring 
only the control data necessary to carry out the specific task. 
For large projects design control information can be physi- 

35 cally segregated by library, version and level to minimize the 
bottleneck caused by too many users accessing the same 
physical server. In the case of the design data, the physical 
data is tracked via pointers whenever possible, so as to 
minimize the amount of file movement between servers. 

40 Although, the "official" control information is centralized in 
one place, the DCS permits certain data to be cached locally 
on the users machine to improve performance by reducing 
traffic to the Design Control Repository. For example, much 
of the control information for private libraries can be cached 

45 locally in order to maximize performance for private library 
accesses. For public libraries, the DCS allows the user to 
take "snapshots" of a library in which the image of the 
library is refreshed locally. The user continues to work with 
his local image of the library until he deems it necessary to 

50 refresh the image. The amount of control data that is actually 
cached is dependant on the environment and the actual 
implementation. Many of the performance issues are dis- 
cussed further in the Sections to which they pertain. 
Libraries and Design Control Repository (Section 1.2) 

55 The Design Control System has two important compo- 
nents. The Design Control Repository contains the control 
information for all components of the design. This includes 
such things as the names of all the pieces, the type of data, 
the level, the version, the owner, and any results which are 

60 deemed quality control records. These results indicate the 
"degree of goodness" of the design component and they are 
used by the DCS to make decisions regarding the type of 
actions which can be performed on a piece of data. This 
repository can be and is preferably implemented in the form 

65 of a database (relational, object oriented, etc.) on using a 
flat-file system. The actual implementation is usually based 
on the environment. 
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As we have said, and as illustrated by the machine to Our model thus consists of one anchor (with a name 235) 

person interface depicted by FIG. 2, our program of instruc- and one or more associated components, each of which is a 

lions executable by a supporting machine environment for data object in said data management system. This means that 

performing method steps by an aggregation manager of a our components can belong to any level and version of any 

data management system having a library organization 5 library in said data management system and said compo- 

which receives a request of a user initiated from said neots are not restricted to the same library, level and version 

displayed client screen as illustrated by FIG. 2 and fulfills as the anchor, and our components can and do comprise 

the request by a providing a result which provides a dynamic multiple data types, including data generated by tools of said 

way to track a model during its course through its design data management system and third party tools, 

phase via our data management system's aggregation man- to Now once a model is created or otherwise identified, it 

ager becomes part of our system. Indeed the second component 

In order to make a common model, we display for is our Design Libraries. They hold the actual pieces of 
creation of a model one or more control screen sections design under the control of the system. There is no limit to 
which provide our control information components 235, ttc number of libraries under the management of the Design 
236, 237, 238, and 239 as part of a control panel input screen Control Repository, and hierarchical designs are allowed to 
allowing creation of a model by interactive user activity, by traverse through multiple libraries. The libraries are man- 
importing a file listing providing the data of screen sections aged by Data Managers (Librarians) who are members of the 
235, 236, 237,' 238, and 239, by searching of a library of files design team. All major facets' of the libraries are program- 
in said data management system and importing a located file mable so they can be tailored to the needs of the design 
containing the data of screen sections 235, 236, 237, 238, 20 group they service. Certain design groups require more data 
and 239, or by use of an application program interface with control than others, so the flexibility exists to widely vary 
a collection of model management utilities which provides the degree of data control. Libraries are categorized as 
the data of screen sections 235, 236, 237, 238, and 239. Public or Private. Both can be shared, but the main differ- 
These data fields of our control screen which when created ence is that a private library is managed by the actual 
by a user comprise data entered in the form boxes (a form 25 designer. It's used to hold his daily updates and often will 
is a screen section entry field for representing a model) have no formal control. The DCS achieves this by defaulting 
illustrated in FIG. 2, and when retrieved or otherwise all control information to a simple non-restrictive form. For 
obtained by the system by importing a file listing providing example, any designer can create private libraries on their 
the data of screen sections, by searching of a library of files own. They automatically become the owner and have the 
in said data management system and importing a located file 30 right to make additional designers "backup" owners. As the 
containing the data of screen sections, or by use of an owner they can edit, save, modify, or delete any data in their 
application program interlace with a collection of model library. The DCS automatically establishes all the proper 
management utilities all provide the data of a control screen AFS and AIX permissions. Owners of private libraries 
panel sections which include: control who can access their data with the system accom- 

(a) a display screen section displaying a first field reprc- 35 niodating the use of default "access groups" (such as AFS 
scnting the name (235) of an anchor name field of a model &° U V*) 50 designer doesn't have to enter the usends of 
which is identical to the name of a data object which is all his team members each time he creates a new library, 
serving as a named anchor, Since Privatc Libraries are considered working areas, data 

(b) a display screen section displaying a second field contro1 f*** are m*"™* in order to maximize perfor- 

represendnT a library (236) where said named anchor 40 "T^ v^V Ti t ^ * T ' 

y . , & ' v ' the DCS does not check the Control Repository to make sure 
resides' 

, ' the owner has the proper authorities, locks, etc.. Instead, a 

(c) a display screen section displaying a third field rep- designer fe to work in a completely unrestricted 
resenting the type (237) of data object identified by said { ^ on ^ h]s Qwn WQfk space ^ COQtrols m placed on 
anchor name; 45 publ i c libraries. The only control checking required is to 

(d) a display screen section displaying a fourth field ensure there are no data conflicts within the Private Library, 
representing user entries for tbe version (238) of said named It ^ acceptable for two Private Libraries to contain the same 
anchor; design data, so no checks across libraries are done. Public 

(e) a display screen section displaying a fifth field repre- Libraries are the official project data repositories. All data 
senting user entries for the level (239) of said named anchor so delivered to external customers comes from Public Librar- 
for use by a user or a third party tool for creating, modifying ies. Public Libraries are overseen by Data Managers who 
or deleting an aggregate collection of data objects, encom- configure the libraries with varying degrees of control, 
passing those used for items that are identified, tabulated, Typically the libraries are organized with a level structure 
tracked, validated and invalidated, and promoted, as are bills whereby the lowest levels have the least amount control, 
of materials, by said data management system. ss Control gets more stringent as the levels increase, and the 

Furthermore, while, as in the other cases for entry section highest level denotes data released to manufacturing. Almost 

fields, the same screen does not have to, but can, display an every attribute concerning data integrity is programmable by 

additional field which displays status information. Thus, as the Data Manager. Through a Data Manager Utility, they 

illustrated by FIG. 2, the system provides a display screen configure the structure (the number of levels and versions, 

section displaying a sixth field representing user entries for 60 including tbe connections between them), the various 

the status of said named anchor. Now each field can be authorities, the required criteria to enter each level, and the 

display separately and various combinations can be made, types of Library Controlled Processes required at each level, 

but all fields are provided by and used by our system. At any The system can handle numerous public libraries, and each 

time, the entire model schema can be displayed, as it is in tbe public library can service unlimited users. In accordance 

field 240, which displays several models names, as well as 65 with our preferred embodiment of our DCS architecture we 

their anchor, type, library, version, level and status (which is provide an Automated Library Machine (ALM). More than 

dynamically tracked by our system). merely a repository for data, the ALM is a userid capable of 
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accepting, executing and dispatching tasks without any 
human intervention. This enables the designers to make 
requests of the ALM to promote data or run library processes 
without the need for a Data Manager to process it. 

Id order to improve throughput, the ALM can dispatch 
parallel tasks if the operating system (i.e. AFS) supports it 
and the situation allows it. 

This concepts improves efficiency, and increases security, 
since the ALM is the only user that requires writable 
permissions to the data repositories. The physical location of 
the data residing in Public libraries is determined by the 
Data Manager. The DCS along with the Data Manager (and 
his alternates) are the only means of writing data into or 
removing data from these physical locations. As a means of 
safety, the Data Manager does have the ability to access and 
overwrite data in these physical locations without using the 
DCS (i.e. thru the OS). This is necessary in the unlikely 
event the control information gets out of sync with the 
physical data, and the Data Manager has to manually com- 
plete a transaction. Physical locations are defined through 
the Data Manager Utility for setting up Public Libraries. 
More details on this are available in the Data Manager User 
Interface Section 15. 

Data Types (Section 1.3) 

Data may be identified by a filename (anchor name 235) 
and a filetype (236). The DCS automatically segregates all 
data by "type". Types are very useful to associate a piece of 
data with a tool or process. For example, UNIX/AIX uses 
extensions to qualify data such as using a ".ps" extension to 
denote a postscript file. The Cadence Design Management 
System uses Cell Views to segregate the various types of 
data within a particular Cell (design component). This 
segregation is a fundamental building block to Design 
Control Systems since certain types of data require more 
design control than other types. Our DCS allows each 
individual type to be controlled on a level and version basis 
within a library. The DCS is capable of tracking any data 
type from any point tool, even third party vendors. 

Levels (Section 1.4) 

Each Public Library consists of n levels which are estab- 
lished by the Data Manager. The naming of the levels (239) 
are arbitrary, but each denotes a degree of quality of the 
design. Data moves into and out of levels via a "promotion" 
mechanism. There are two types of levels in the DCS, 
Engineering (or working) and Release Levels. 

FIG. 3 shows a typical level structure with 3 Engineering 
Levels denoted El, E2 and E3, two main Release Levels 
denoted Rl and R2, a Sideways Release Level SI, and a Fast 
Path Stream consisting of F21 and F22. Data can be pro- 
moted into El, F21, E3 and SI from outside of the library, 
but it can only enter R2 from E3. El, E2 and E3 are arranged 
in a serial fashion. The normal promotion path is for data to 
enter El (the least controlled level) and migrate up through 
E2, E3 and finally into R2 (the most tightly controlled level). 
The external paths into F21 and E3 are known as "fast paths" 
and exist to accommodate emergency updates to pieces of 
design residing at the higher levels. There are two different 
types of fast path arrangements: 

Fast Path Entry means there is no fast path level associ- 
ated with the Engineering level, just a "doorway" 
through which data can enter. Level E3 is an example 
of this where the user simply promotes data from the 
private library into E3. The DCS will run any pre- 
processes defined at E3, but any criteria that would 
normally be necessary to traverse through El and E2 is 
bypassed. 
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Fast Path Levels are staging areas where data is promoted 
into, and promoted through, in order to reach the target 
Engineering Level. There can be any number of Fast 
Path levels for any given Engineering Level. If there's 
5 more than 1, it's known as a Fast Path Stream since the 
data must migrate through all the Fast Path Levels 
before reaching the Engineering Level. F21 and F22 
constitute a stream, which could 've contained more 
than 2 levels. We have provided at least one level to 
10 provide an area where all the processing normally run 
at the El and E2 levels can be run to ensure that the fast 
path data meets all the same criteria. 
Release Levels are handled in a different manner. Rl is 
the oldest release level and it's frozen, which means its 
15 contents can't be updated any longer. It contains a static 
snapshot of a design delivered to an external customer. R2 
is now the active Release Level which is the destination of 
any data promoted from E3. The Data Manager programs 
the connection of El to E2 to E3 to Rn. The DCS automati- 
20 cally freezes the previous Release Level and connects E3 to 
the new Release Level whenever the Data Manager creates 
a new one. Unlike main Release Levels, Sideways Release 
Levels are always active and there can be n Sideways Levels 
for each Release Level. The purpose of the Sideways Levels 
25 is to bold post tape-out updates such as microcode patches 
to hardware under test. Since the Release Level correspond- 
ing to that level of hardware is probably frozen, and a new 
iteration of design is propagating through the Engineering 
Levels, the only path into a Sideways level is directly from 
30 a Private Library. The Data Manager has the ability to 
reconfigure the Engineering Levels at any time based on 
these rules: 

The connections between levels can be changed at any 
time. (i.e. E— * , E2-» , E3 can be changed to 
35 E1^E3^E2.) 

A level can be removed as long as no data resides in that 
level. 

A level can be added at any time. 
^ The Data Manager can create a new Release Level at any 
time. Existing frozen Release Levels can be removed as long 
as no data resides in that level. A frozen level can become 
an active level again if no data resides in the current active 
Release Level. The DCS performs a "thaw", a step which 
removes the current Release Level (R2) and connects the 
previous level (Rl) to E3. As shown in FIG. 3, the DCS 
supports the normal promotion path to El as well as "fast 
paths" into E2 and E3. The following minimum checks are 
performed at all entry points: 
50 The owner attempting to send data to a Public Library 
must possess the update lock. If no lock exists, the 
sender obtains the lock by default. If another user has 
the lock and the sender is a surrogate, he can obtain the 
lock (the system immediately notifies the original 
55 owner). If the sender is not a surrogate, the action is 
halted, until ownership is properly transferred. 
If the level to which the data is being promoted to has any 
entry criteria, it is checked to ensure the data passes the 
criteria. 
60 Versions (Section 1.5) 

Each public library consists of n versions which are 
defined by the Data Manager. The concept of versions exist 
to support parallel design efforts. All versions have the same 
Engineering (Working) Levels, but have different Release 
65 Levels depending on the frequency of tape-outs for that 
version. Data in separate versions is permitted to traverse the 
levels at independent rates. For example, if a piece of design 
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has 2 versions, 1 version may exist at El while the other 
version exists at E3. FIG. 4 is an extension of FIG. 3 in 
which library structure has been expanded to show 3 
versions, VI, V2 and V3. In theory there's no limit to the 
number of versions just as there's no limit to the number of 
levels. Versions can be independent or dependent. Indepen- 
dent versions are isolated and must ultimately contain the 
entire set of design components. Dependent versions are 
based on previous versions (which the Data Manager speci- 
fies when creating a new version). By supporting the concept 
of dependent versions, only the incremental data necessary 
for a new design variation needs to be libraried in the new 
version. The Library Search mechanism will be able to 
construct a complete design Bill of Materials by picking up 
data from both versions, 
library Search (Section 1.6) 

Our preferred embodiment of the DCS provides support 
for "Library Searches". This allows data, which is used in 
multiple iterations of the design, to exist in only one place. 
In other words, if a design component is changed, only that 
component needs to be re-libraried at a lower level. A full 
model can still be constructed by starting the search at the 
lowest level where the component is known to exist. The 
library search mechanism will pick up the latest pieces at the 
lowest level, then search through the next highest level to 
pick up more pieces, and so on until it reaches the highest 
level where all components reside. In addition to searching 
through levels, the mechanism also searches through ver- 
sions. The user provides a starting library level, version and 
either a single type or a list of types. If the version is based 
on a previous version, and all the necessary design compo- 
nents can't be located in the starting version, the mechanism 
searches the previous version based on the following two 
rules: 

1. If the search begins at an Engineering Level in one 
version, it resumes at the same Engineering Level (not 
the lowest level) in the previous version. 

2. If the search begins at a Release Level (including a 
Sideways Level) in one version, it resumes at the latest 
Release Level in the previous version. This may be 
older or more recent in time than the released data in 
the current version. 

FIG. 5 shows examples of the Library Search Mechanism. 
The library search utility is available to designers, Data 
Managers and third party tools. The interface is both 
command-line and menu driven to accommodate any envi- 
ronment. In addition to the required parameters of type, level 
and version, the user has the option of specifying the name 
of a data object. These additional options exist: 

Noacc 

This allows the utility to use a temporary cached copy of 
the search order information for performance reasons. 
Since this information may be obsolete, the absence of 
the option results in the actual Design Control Reposi- 
tory being accessed and the search performed from 
within it. 

File 

Write the results into an external file. 
Various Sorts 

They control the way the output is sorted and displayed. 
Nosearch 

Only list data found at the starting level. 
First/All 

Indicates whether to include all existences of a particular 
design component or only the first one in the search 
order. 
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Select 

Presents a selection list of all candidates so the user can 

choose those of interest. 
Noversion 

Prevents the search from tracing back across version 

boundaries. 
Levels 

Displays the search order based on the existing level 

structure. 
Versions 

Displays the search order based on the existing version 

structure. 
Locks (Section 1.7) 

In order to properly control shared data, the DCS supports 
several types of locking mechanisms. Two of the locks exist 
to control groupings of files that may comprise a model 
build: These are known as move and overlay locks. The user 
can set one of these locks using a utility which allows him 
to control the scope of the lock based on certain fields. The 
user can enter specific data or a wildcard, indicating "ALL", 
for 

Name of Design Components 
Type of Design Components 
Level of Design Components 
Version of Design Components 
Library Name 

By specifying only a library name and four wildcards, the 
user is requesting that all data in the library be locked. By 
filling in all five entries, a specific design component will be 
locked. Various degree of locking exist in between those 
extremes. 

If the information corresponds to a Bill of Materials 
(BOM) and the user wants to set the lock on the entire BOM, 
a BOM Flag will exist allowing him to specify this action. 
Regardless of how these fields are filled in, all locks will be 
set individually so they may be removed individually. A lock 
does not have to be removed the same way it was set. The 
user will also specify the type of lock, Move, Overlay, or 
Update (Ownership). The following definitions exist: 
Move Locks mean the data can't be overlaid by the same 
data at lower levels, nor can it be promoted to a higher 
level. This provides a method for completely freezing 
an Engineering Level while a model build or large scale 
checking run is in progress. 
Overlay Locks are a subset of move locks. The data can't 
be overlaid by the same data from lower levels, but it 
can be promoted to higher levels. 
Update (Ownership) Locks are the means by which a 
designer takes ownership of a piece of data. Update 
locks are designed to prevent multiple designers from 
updating the same design component in an uncon- 
trolled way, thus resulting in data corruption or lost 
information. There are two types of Update locks, 
permanent and temporary. 
A permanent Update lock exists when the designer spe- 
cifically requests to own a piece of data. This is done through 
a utility, and the DCS keeps track of this ownership. Other 
designers may copy and modify the data in their private 
libraries, but any attempt to promote that data into the public 
library will fail, unless the designer is a designated surrogate 
of the owner. The only way these locks are removed are by 
the owner resigning the lock or a surrogate assuming the 
ownership of the data, and the corresponding lock. A tem- 
porary Update lock exists to facilitate sharing a piece of data 
among multiple designers. The user can either request a 
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temporary Update lock in advance (i.e. when he begins 
editing the data), or he can wait until be initiates the promote 
into the public library. The DCS will first check to sec if 
anyone has a permanent Update lock, and if so, it will only 
allow the promotion to continue if the user is a designated 
surrogate. If nobody has a permanent Update lock, then the 
DCS will issue a temporary Update lock for the time the data 
remains "en route" to the final promote destination. Once it 
arrives safely, the temporary Update lock is removed and the 
data can be claimed for ownership by someone else. Surro- 
gates are "alternate" owners of data. For example, a project 
may be arranged such that each piece of design is owned by 
a primary designer, but also has a backup owner (designer) 
to take over the design during vacations, emergencies, etc.. 
In this case, the owner can tell the DCS that the backup 
designer should be a surrogate, thus giving him the right to 
take ownership of a design component. The surrogate can 
-either use the locking utility to specifically take ownership 
prior to making any updates, or he can wait until he initiates 
a promotion. The DCS will check to see if the design 
component is currently owned, and if so, check to see if the 
user is a defined surrogate. If both are true, it will give the 
user the chance to "take ownership" and allow the promote 
to continue. The original owner would be notified that his 
surrogate has taken ownership. FIG. 6 illustrates the lock 
mechanisms for Update locks. 

Bill of Materials Tracker (Section 1.8) 
The DCS has a built-in Bill of Materials (BOM) Tracker 
to facilitate tracking many design components in large 
projects. The main objective of the BOM Tracker is to group 
certain design components to make it easier to promote them 
through the library and track their synchronization. This is 
crucial for data sets that contain some source and some 
derived files from that source. The following features exist 
in the BOM Tracker: 

It supports automatic data grouping, based on the design 
component name, with the notion of required and 
optional data types. One example might be a grouping 
which consists of a graphical symbol denoting the I/O 
of a design component, the corresponding piece of 
entity VHDL and the architectural VHDL. Any changes 
made to the symbol should be reflected in the entity, so 
the entity would be required. A change may also be 
made to the architecture, but it's not always necessary, 
so the architectural VHDL would be optional. When a 
promote is initiated to a public library, or between 
levels of a public library, the DCS checks to see 
whether a data grouping is defined for the data type 
being promoted. If so, then all required data types are 
checked to ensure they exist. In addition, any optional 
data types are checked for existence and they are also 
picked up. The entire grouping is promoted to the target 
level. If a required data type does not exist, the pro- 
motion fails. Automatic data groups are programmed 
into the DCS by the Data Manager. Since they are 
BOMs, all rules of BOM tracking, invalidation and 
promotion exist for the members of the grouping. 
BOMs are used for two main reasons. First they are used 
to group many smaller pieces of data into larger more 
manageable chunks to facilitate movement through the 
library and increase data integrity by reducing the risk 
of data getting out of sync. The other main reason is to 
track the components of a model (i.e. simulation, 
timing, noise analysis, etc.). The DCS offers a very 
flexible user interface for creating BOMs in order to 
satisfy the various scenarios. The user can manually 
create BOMs by selecting pieces of design 
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interactively, filling in search criteria and initiating a 
library search, or importing a simple text list. In 
addition, an API exists for point tools to create a BOM 
listing and pass it into the DCS. 

The power of the BOM Tracker is augmented with our 
automatic invalidation routine. Once a BOM is created, 
the DCS constantly monitors for a change to the BOM. 
If any member is overlaid or deleted, a notification is 
sent to the owner of the BOM indicating that the BOM 
is no longer valid. The owner can continue to work with 
his model, but he is aware that he's no longer using 
valid data. Even though a BOM is invalid, it can still be 
moved through the library. This accommodates the 
occasion where a piece of a model had a relatively 
insignificant change. If the model builder deems it 
unnecessary to re-build the model, this feature allows 
him to continue his work and even move the BOM 
through the library. 

Status on BOMs is and should be accessible in two ways. 
The first is by automatic notification (e.g. e-mail) to the 
owner as soon as a BOM is invalidated. The second is 
by means of displaying the BOM either interactively or 
in report form. This listing shows the overall status of 
the BOM, and all members of the BOM with their 
individual status. 

The BOM Tracker also supports the concept of a "sup- 
port" object. This can be a design component, a piece 
of information, documentation, etc., that can be asso- 
ciated and promoted with a BOM but never causes 
BOM invalidation. 

BOMs are hierarchical in nature and a BOM can be nested 
within a larger BOM. Whenever a piece of data is 
overlaid or deleted, the DCS looks to see if that piece 
belonged to a BOM. If so, it immediately checks to see 
if the BOM belongs to other BOMs. It recursively 
checks all BOMs it encounters until it's at the top of the 
hierarchy. All BOMs found will be invalidated (if they 
are currently valid) and the owners notified. 

BOMs support move and overlay locks. The user can set 
a move or overlay lock on a BOM, and the DCS will 
set individual locks on all the members. If a member is 
a BOM, all of its members will receive individual 
locks. These locks can be removed by using the main 
lock utility and specifying the top-level BOM or filling 
in the desired fields to individually reset locks. 

The DCS supports the concept of a BOM promote, which 
means the user can request that all the contents of the 
BOM be promoted simultaneously. This increases data 
integrity by helping to ensure a matching set of design 
data traverse through the library in sync. 

BOMs can contain members who reside at different 
levels, different versions and even different libraries. 
The DCS will only promote those members which exist 
in the current library, and reside in an Engineering 
Level below the target level. If a member exists in a 
different version and is also below the target level, it 
will also be promoted. 

There is separate authorizations for creating and promot- 
ing BOMs. This is set up by the Data Manager, so they 
can have complete flexibility in controlling who can 
create and move BOMs. 

Promotion Criteria and Promotion Mechanism (Section 
1.9) 

An important aspect of the DCS is that it provides a 
method for the design to traverse to different levels of 
goodness. As the design stabilizes at the higher levels, the 
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number of pieces which need to be moved and tracked can 
be very large. The DCS uses the concept of promotion 
criteria and robust mechanisms to first determine what data 
can be promoted, then carry out the task in an expedient 
manner. The DCS supports two variations, "move" and 
"copy", promotes. In a "move" promote, data appears to the 
user like it only exists at the target level once the promote 
completes. The user is unable to access the copy that existed 
at the previous level. For example, if a design component is 
at level E2 and the user promotes it to E3, when the promote 
is finished and the user refreshes his image of the library, he 
sees the data at E3 only. In a "copy" promote, the data still 
appears at the previous level. The user can access it at either 
location. As new iterations of the same design component 
are promoted into a level, the old component is not truly 
overlaid. It is moved off to the side so it can be restored in 
an emergency. Promotion criteria usually exists in the form 
of library process or pseudo-process results, but in general 
it can be any condition that must be met by the the object(s) 
being promoted. It is defined by the Data Manager and can 
exist for any design component at any level and version. 
Certain design components don't undergo any formal check- 
ing or evaluation in the design process, so they may never 
have any promotion criteria. Other pieces may undergo the 
majority of checking so they may have lots of criteria. The 
objective of the DCS is to track actual results for each design 
component and use the promotion criteria to determine if the 
design can attain the next level of goodness. When a design 
component is overlaid or deleted, all corresponding results 
are deleted too. The DCS supports an emergency override 
mechanism which allows the Data Manager to promote data 
which does not meet the criteria. Invoking an emergency 
override cause a log entry to be written indicating criteria 
has been bypassed. The Data Manager determines which 
results are necessary for which types of design at each 
Engineering and Release Level. These results may get 
recorded through "library controlled" or "external" process- 
ing. At the time the promote is initiated (whether it be 
against individual design components or BOMs), the mecha- 
nism illustrated by FIG. la and FIG. lb is invoked to 
determine what pieces should be promoted. There are three 
types of promote transactions. 

1. Promotion of an Individual Design Component 

2. Promotion of a Group of loosely-coupled Design 
Components 

3. Promotion of a Group of tightly-coupled Design Com- 
ponents (i.e. BOMs) 

Basically, the same mechanism is employed in all three 
cases, but cases 2 and 3 require additional optimization for 
high performance. In case 1, each step in the mechanism is 
executed once and the promotion either succeeds or fails. 
Case 2 is initiated by a user selecting a group of objects to 
be promoted. They may or may not have any relation to each 
other. In this case some optimization is done, but each object 
is basically treated as if it were initiated as an individual 
promote. For example, the authority check only needs to be 
done once since the same user is requesting the promotion 
for all the objects. However, since each object can have 
unique locks, criteria, processes defined, etc., most of the 
steps need to be repeated for each object. Case 3 is the most 
complicated because the DCS offers a great deal of flexibil- 
ity. The actual implementation is dependent on the platform 
of the DCS and the type of control mechanism in place 
(file-based, object oriented database, relational database, 
etc.). If the user community wants to eliminate flexibility in 
return for increased performance, the DCS can enforce rules 
such as no library processing allowed for members of a 
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BOM. In this scenario, the entire algorithm would be 
executed on the BOM itself to ensure the proper authority is 
in place, it meets the promotion criteria, and any processing 
that's defined is executed. However, each member could 

5 bypass some of the checks thus saving a significant amount 
of time. If the user community opts for flexibility, some 
optimization can still be performed. For example, if a BOM 
contains 10 members and the mechanism calls for five 
checks on each member, there doesn't need to be 50 requests 

1Q for information. Depending on the platform, it may be 
optimal to either make one large request for each member 
(ten total requests) and obtain all five pieces of information 
in the request. In other cases it may be optimal to initiate a 
request for a piece of information, but solicit it on behalf of 

15 all ten members (five total requests). Since these BOMs can 
be extremely large, the various kinds of optimizations and 
tradeoffs between flexibility and performance determine the 
exact implementation. As a convenience- feature the* DCS 
supports a multiple promote feature which allows the used 

2Q to request a promote through multiple levels. For each level 
the promotion mechanism is followed as stated above. For 
example, when initiating a promote, the user can specify to 
move data from El to E3 with a single invocation. However, 
the DCS will internally break it into two separate promotes 

25 with the full mechanism being run for the El to E2 promote, 
then again for the E2 to E3 promote. 

Library Controlled Processing (Section 1.10) 
The concept of Library Controlled Processing allows 
tasks to be launched from a public library, against one or 

30 more design components, with the results being recorded 
against the components. This is an automated method to 
ensure that tasks, and checks deemed critical to the level of 
design are run and not overlooked. Since some of these tasks 
could be third party tools, the actual implementation can 

35 vary in sophistication. In its simplest form, Library Con- 
trolled Processing consists of the following constituent 
parts: 

Foreground Processing: 

This is the conduit by which the user enters any infor- 
^ mation required to run the tool. Menus may be pre- 
sented or the user may interact in some other way. 
Pre-Processing: 

This refers to a library controlled process that is launched 
prior to the data being promoted to the target level. The 

45 process must finish and complete successfully, based 
on the promotion criteria of that process, if the promote 
is to continue. For example, if a pre-process is defined 
at level E2, then when the promote to E2 initiates, the 
process is launched and the promote "suspends" until 

50 the process completes. Once it finishes, the result is 
compared against the criteria to ensure it's satisfactory. 
The promote then resumes. 
Post-Processing: 

This refers to a library controlled process that is launched 
55 after the data arrives at the target level. The results of 
the process are used as promotion criteria to the next 
level. 

Designer Initiated Library Processes (DILP): 

This is very similar to a post process, but instead of the 

60 DCS launching the process, it's manually launched by 
the designer. DILPs usually exist to retry Post- 
Processes which failed. This eliminates the need for the 
user to re-promote the data just to initiate the process- 
ing. If a DILP is used to recover a failing Post-Process, 

65 and the DILP is successful, the good result will over- 
write the bad result from the Post-Process. Just because 
DILPs are primarily used to recover failing Post- 
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Processes, the DCS doesn't make this a restriction. The 
Data Manager can set up DILPs as stand-alone pro- 
cesses with no corresponding Post-Process. DILPs that 
exist to recover failed Post-Processes are optional in 
that they are not counted as required promotion criteria. 
Stand-alone DILPs can be optional or mandatory, with 
mandatory DILPs being required to run successfully in 
order for the data to promote to the next level. The DCS 
allows the Data Manager to designate which DILPs are 
mandatory and which are optional. 
Level Independent feeudo Processes: 
These are special types of process which are more like 
process results than actual processes. They exist as a 
means to record information outside of the scope of 
results from Library Controlled Processes or External 
Data Processing. For example, suppose a Library Pro- 
cess exists to run a layout checking program which 
checks' for wiring and ground rule Violations. Ulti- 
mately the program will return some pass/fail result, 
such as a return code, which the DCS uses as the 
process result. The tool may also return other useful 
information which the designer wants to save, such as 
the number of wires or cells in the design. Pseudo 
processes provide a repository for this kind of data. 
Like DILPs, these can be used as mandatory criteria for 
promotion, or they can be optional and used solely for 
information. They can even serve as status indicators 
for design components progressing through a lengthy 
process at a particular level. The concept of level 
independence means the checking program could be 
run at the E2 level, but the pseudo process results can 
be stored at E3. In short, the DCS allows a pseudo 
process to be defined at any level, and it can be set by 
a process running at the same level, any other level or 
completely outside of the library. The DCS provides an 
API for setting level independent pseudo processes. 
The API can be used by designers, Data Managers or 
third party tools, and employs a "process search" 
similar to a library search. This means the API allows 
the user to specify the name of the process, the data 
type, level and version. The DCS will use this as a 
starting level and search for all matching pseudo pro- 
cesses denned at or above this level by following the 
same library search mechanism as in FIG. 5. A flag also 
exists to disable the search and set the result for the 
process specified at that level and version. 
Any number of any type of process can be defined by the 
Data Manager for a given data type at a particular level and 
version. In addition, processes can be chained together in 
independent or dependent sequences. In a dependent 
sequence, each process must complete successfully before 
the next process in the chain can initiate. For example, when 
compiling VHDL, the entity must always be compiled prior 
to the architecture. Thus two compiles could exist as a 
dependent sequence where the entity is compiled, the result 
checked, and if successful, the architecture is compiled. In 
an independent chain, the first process initiates, and when it 
completes, the next process runs regardless of the outcome 
of the first process. Processes can also execute using input 
data other than the object used to initiate the promotion. 
Using the VHDL compile example, the actual object being 
promoted could be a simulation BOM which contains that 
entity and architecture VHDL. The DCS provides a robust 
system for the Data Manager to define the processes which 
should be run, and the type of data they should run on. 
Certain library controlled processes require special 
resources such as large machines, extra memory capacity, 
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etc.. Therefore, the DCS allows the Data Manager to specify 
a particular machine or pool of batch machines where the 
tasks can execute. Either the task is transferred to the 
specific machine or a request is queued up in the batch 

5 submission system. In the event that a task must run on a 
completely different platform, the DCS provides hooks to 
launch a library controlled process from one platform which 
initiates a task on a different platform (i.e. a mainframe). The 
results are returned back to the original Automated Library 

10 Machine and processed. This Cross-Platform capability 
allows the DCS to encompass a broad and sophisticated 
methodology utilizing tools on many platforms. Regardless 
of how the process is launched, the results must ultimately 
get recorded within the DCS. To accomplish this, the DCS 

15 provides an Application Program Interface (API) through 
which third party tools can communicate. When the task 
completes, the API is used to convey the results and the 
pedigree information back to the DCS. The DCS provides 
both an interactive means and a report generator to view 

20 process results. FIG. la and FIG. lb illustrate the method by 
which promotions and library controlled processing interact. 
External Data Processing (Section 1.11) 
External Data Control is very similar to the Designer 
Initiated Library Process in that the user launches a task 

25 against some design components). However, unlike DILPs 
which require that the design components be under the 
control of a Public Library, this type of processing is done 
on data in Private Libraries and designer's work spaces. 
External processing is the mechanism whereby the DCS 

30 captures the results of the process along with pedigree 
information concerning the input data, output data and any 
necessary software support or execution code. This pedigree 
information is stored along with the design component for 
which the designer initiated the process. When the designer 

35 promotes that component at a later time, the DCS checks the 
pedigree information to ensure nothing has changed It then 
checks to see if the external processing matches any of the 
defined library processes which are required for the promote. 
If so, and the external processing results meet the criteria, 

40 the library process results are set (as if the library process 
just ran automatically) and the promote proceeds. If no 
matching process can be found, the external results continue 
to be saved with the design component as they process may 
match that at a later level The concept of External Data 

45 Processing exists to increase productivity by allowing the 
designer to save, and later apply, results obtained during the 
normal course of design rules checking to the "official" 
results the DCS uses to determine the level of goodness. 
Overall data integrity can easily be breached if a proper 

50 mechanism for calculating pedigree information is not 
implemented. For this reason it's imperative for the DCS to 
ensure that all the proper input, output and software data are 
included in the pedigree information. External Data Pro- 
cessing occurs in two phases. In the first phase, the designer 

55 runs some tool or process and if the results are acceptable, 
he runs a utility to designate the data for external processing. 
The role of the utility is to create the Pedigree information 
which contains a listing of the input and output data, the 
results, and some type of date identification code for each 

60 member of the Pedigree and the Pedigree itself. A simple 
identification code is a cyclic redundancy check. The utility 
can be independent of or incorporated into the actual third 
party tool. The second phase consists of librarying the data 
and the results. The designer invokes a special form of a 

65 promote which first does the following: 

1. Check the data identification code (i.e. CRQ of all 
members in the Pedigree 
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2. Check the data identification code of the Pedigree itself. 

These 2 steps are designed to ensure the same data used 
to generate the result is indeed being libraried Hie identi- 
fication code of the Pedigree ensures that the contents of the 
Pedigree weren't manually altered. From this point on, the 
normal promotion mechanism in FIG. la and FIG. 7b is 
followed with one exception. The boxes where Foreground, 
Pre and Post Processing occur are all bypassed. Rather than 
simply checking existing results to see if they meet criteria, 
the DCS makes a list of all Pre-processes for the target level 
and Post processes for the previous level. It then checks the 
Pedigree information for evidence that equivalent processes 
were run and achieved acceptable results. If any processes 
exist in the DCS for which no corresponding Pedigree 
results exist, or any Pedigree result docs not meet the 
prescribed criteria, the promote fails. 

Authorities (Section 1.12) 
"" " The DCS permits the Data Manager to establish/ a wide 
variety of authorities which gives him great flexibility in 
managing the library. Each type of authority can be defined 20 
very loosely (the user is authorized for all design 
components, at all levels, in all versions) to very tightly (the 
user is authorized on an individual design component basis). 
The utility for granting authorities works in one of two 
modes: 

In one mode the Data Manager is offered a screen in 
which he can fill in the design component name, type, 
level, version, user ids, and the type of authority. For 
any field, except for the user ids, he can default it to 
"ALL". 

In the other mode an authority profile can be called up and 
executed. An authority profile allows the Data Manager 
to pre-define the types of authorities for a given type of 
job. For example, profiles may exist for Designer, 
Technical Leader, Model Builder, etc.. This informa- 
tion is contained in an editable ASC file in which the 
Data Manager defines the kinds of authority to varying 
degrees of restriction. Once the profiles are created, the 
Data Manager uses this mode to either add/delete users 
to/from the profile and process the changes within the 
DCS. 

Authorities exist for the following tasks: 
Setting Locks (Move, Overlay, Update, ALL) 
Promoting design components and/or BOMs into levels 

(Engineering Levels, Release Level. 
Creating BOMs 
Initiating Library Processes 
Setting Pseudo Process Results 
Data Manager GUI User Interface (Section 1.13) 
The DCS contains a robust Data Manager interface which 
is used to "program" the library. It's configured as a series 
of sub-menus arranged under higher level menus. Each 
sub-menu has fields to fill in and may employ Predefined 
Function (PF) keys for additional features. Graphical ele- 
ments such as cyclic fields, radio buttons, scrollable 
windows, etc.. may be used to further enhance usability. 
Utilities exist to: 

Define the library properties 

The user is afforded a means to enter the path of the 
repository where the data resides, the userid of the Data 
Manager and any alternates, the userids of any Auto- 
mated Library Machines, and whether the library is 
under Design Fix or Part Number and EC control. If the 
library is under any type of control, additional entries 
are made for the data types which should be tracked by 
Part Number, the data types which should be tracked by 
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Design Fix number, the EC control level, and a field for 
a generic problem fix number. For any ALMs, the DCS 
will automatically add the proper authorities (including 
operating system authorities) to permit the ALM to 
store data and record results. 

Define the structure (levels, versions and their 
interconnections). 

This is the means by which the Data Manager adds and 
deletes levels and versions. It also enables him to 
defined the interconnections of the levels, and the 
dependance of versions on other versions. A minimum 
interface consists of one screen for level structure and 
one for version structure. The level structure screen 
displays the current structure. 

Define the types of data which will be under library 
control. 

For all data types known to the DCS,. this enables the Data 
Manager to select those managed in this particular 
library. The screen displays all known data types in the 
system with a flag indicating whether it's being tracked 
by this library. Each data type also has a field for an 
alternate storage location. This solves the problem 
caused by certain data types that can be very large. 
Therefore, problems may arise in trying to store these 
data types along with the all the other types in a 
particular level. By specifying an alternate storage 
location, these large data types can be further segre- 
gated. 

Manage Library Controlled Processes 
For each level, the Data Manager can add, modify or 
delete processes. For each process information is 
required about the type of machine it can run on, any 
necessary arguments, the result criteria, disposition 
instructions for the output, whether it's dependent on 
another process, and whether it should be deferred. The 
DCS provides Process Specific Boilerplates which can 
be used to manage process configurations for an entire 
project. Necessary and required information for each 
process can be programmed into the DCS, so when a 
Data Manager attempts to define that process to his 
library, some of the fields appear with default data 
already rilled in. He can override any of the data. 
The information for each process can be entered/edited 
individually on a menu containing all the above fields or a 
utility exists to load "process groups" which are pre-defined 
library controlled processes. The Data Manager simply 
selects a process group and attaches it to the appropriate data 
type, level and version. The process groups are ASC based 
files which contain the necessary process information in a 
prescribed format. They can be created using any ASC 
editor. 

Set up authorities. 

See the previous Section 1.12 for details. 
Define automatic data groupings (Subset of BOM 
Tracking) 

This enables the Data Manager to define a data group 
which consists of a master object and member objects. 
Each member object can be required or optional. For 
each master object entered, the user must enter a list of 
member objects with their required/optional flag. In 
addition, an Erase-To-Level flag exists which deter- 
mines the outcome of the following scenario: a data 
group, comprised of optional members, exists at a 
level. The same data group, without some of the 
optional members, exists at the next lowest level. Upon 
promotion of the lower level data group, the DCS will 
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either erase the members of the upper level data group 
or leave them, depending on the Erase-To-Level flag. 
By leaving them in place, it allows members of newer 
data groups to join with members of older data groups. 
Design Fix Tracking (Section 1.14) 
One of the most powerful aspects of our DCS is provided 
by the process used to track fixes to design problems. This 
is accomplished by tightly or loosely coupling the DCS to a 
problem management database. Typically, a problem is 
found and entered in the problem tracking database. Once 
the design components are identified which require 
updating, the DCS is used to attach the problem number to 
those design components. Ideally this should be done prior 
to the design components entering the library, but it can be 
done as part of the promote. It's often redundant to track all 
design components with problem numbers, so the DCS cao 
be programmed to only enforce Design Fix Tracking on 
certain data types. Whenever a promote is initiated, the DCS 
checks" to see if the library is in Design Fix Tracking mode 
(which means some data types require Fix problem numbers 
to enter the library), and looks to see if any of the data types 
included in the promotion are being tracked For those that 
are, a screen displays all known problem fix numbers for that 
design component. The user can select an existing one or add 
a new one to the list. At this time, the DCS will check to see 
if the EC control level is being crossed (or bypassed via a 2 5 
fast path promote). If so, it will attempt to associate the 
problem fix number to an EC identifier. If it can't automati- 
cally determine this association, the user is prompted to 
enter the EC identifier for the selected problem fix number. 

If the designer chooses to do the association in advance, 
a utility exists which allows him to enter a problem fix 
number or choose a default number. The status is immedi- 
ately reflected as "working". Once the promotion is initiated 
the status will switch to "libraried". The DCS offers utilities 
to view or print reports showing which design components 
exist for a problem or which problems are fixed by a design 
component. The report generator allows the user to enter the 
problem number and see which design components are 
associated to it. Or the design component can be specified to 
see which problems it fixes. Finally, and EC identifier can be 
specified and all problem numbers and design components 
associated with the EC can be displayed 
Part Number/EC C6ntrol(Section 1.15) 
In addition to tracking design fixes, the DCS can track the 
design by part number and/or EC. For projects which assign 
part numbers to various design components, the DCS pro- 
vides utilities to generate and associate these part numbers 
to the design components. In addition, the DCS supports 
Engineering Changes where successive tape-outs are 
assigned an EC identifier. All design components participat- 
ing in an EC are associated with the EC identifier. Since part 
numbers are assigned to specific design components, the 
DCS uses the links between components design fixes and 
EC's to track the association of part numbers to ECs. The 
DCS uses the concept of a PN/EC control level to permit the 
Data Manager to determine at which level PNs and Design 
Problem numbers get associated with EC numbers. As 
design components cross this level, the DCS checks to see 
whether a problem number or PN exists for the component. 
If so, and the system is able to determine which EC that 
number is associated with, it automatically connects the 
component to the EC. Otherwise, if no EC information can 
be found, the user is asked to enter it. The rules for Design 
Fix and EC control are as follows: 

One EC can contain multiple Design Fixes; 
Any single Design Fix # (number) can only be associated 
with a single EC; 
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One design component can have many Design Fix 
numbers, but they must all belong to the same EC; and 
Variations of a design component can exist in multiple 
ECs, but each must have a unique set of Design Fixes. 
FIG. 8a illustrates a legal example. It shows two EC's 
where the first contains two design fixes and the second 
contains a single design fix. There are three design 
components, of which the one denoted AO is associated with 
Design Fix #1 and Design Fix #2. Design component Al is 
a different variation of design component AO The example 
shows how the two versions of design component A must 
belong to separate ECs. In FIG. Sb the rules have been 
violated since design component Al is associated with 
Design Fix #2 which belongs to EC #1. The DCS detects this 
condition and alerts the user to either move Design Fix #2 
over to EC #2, or detach design component Al from Design 
Fix #2. In addition to tracking all the part number and EC 
information the DCS is capable „of generating a variety of 
reports including one listing all the part numbers for a given 
EC This report can be sent to manufacturing in advance so 
the foundry can manage their resources. 
RAS and Security (Section 1.16) 
The DCS is designed in such a manner that provides 
maximum security for the control data. None of this data is 
present in simple ASC files residing in a writable repository. 
All updates to this information must be made through the 
proper utilities by authorized people. Libraried data only 
exists in repositories where the Data Managers or owners of 
the data have write permission. This prevents other users 
from modifying another designer's data outside of the DCS. 
Nearly continuous availability is achieved by implementing 
the DCS in the following manner: 

If the primary DCS server fails, the system can be brought 
up on another server with minimal human intervention. 
The physical locations of all libraries are determined by 
the Data Manager which permits the data to be strate- 
gically located throughout the network to improve 
availability. 

Multiple paths exist to request information from the 
Control Repository. They provide alternate routes in the 
event of network or router problems. 

Archiving and backing up data is accomplished with the 
following features: 

The Design Control Repository can be archived onto tape 
or backed up to another repository by the Data Manager 
as often as deemed necessary. In the event of 
corruption, this back up copy can be restored into the 
primary repository. 

All libraries can be archived to tape or backed up to 
alternate repositories defined by the Data Manager as 
often as deemed appropriate. 

The DCS provides a utility which checks to see if a 
backed-up or archived copy of the Design Control 
Repository is in sync with a backed up or archived copy 
of a library. During the archiving procedure, the system 
assigns unique identification codes (i.e. CRC codes) to 
each data object These codes are used during the 
recovery to ensure the data was not tampered with 
while dormant on the back-up repository. 

The system provides a method for restoring individual 
data objects from backed-up or archived repositories in 
the event the data object is deleted from the active 
library. 

GDI User Interface (Section 1.17) 

The User Interface consists of all the menus, dialog boxes, 
and screens by which the designers interact with the DCS. 
They all have the following characteristics in common: 
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They are user friendly with convenient on-line help. user must also supply the problem fix number. The 

They share a common look and feel to make it easy for the DCS automatically assigns the < Wiring" status to it. 

user to find common features. Later > whcn thc designer wants to promote the 

* i *t_ i *i_ component, the problem fix number will appear on the 

When someUiingfailsorthe user makes an entry error the selec P tioD ^ and after the promote completes, the 

system clearly indicates the error with an English sXm& wfll cfa {Q u^^n ^ DCS allows the 

description of the problem, and suggestions on how to Da(a Maflagcr t0 a gcneric ?roblcm numbcr 

fr* , which designers may select to associate with miscel- 

A command line interface exists to perform any operation laneous design changes that have no corresponding 

that can be done through the graphical user interface. design problem. 

Various designer utilities exist to: 10 WWW/Internet Access (Section 1.18) 

Initiate promote requests. The minimum interface The DCS provides a mechanism which permits access to 

requires the user to enter the name of a design com- all process and pseudo process results through the World 

ponent or select from a list, enter the level from which wide Web. Key quality control indicators can be exported 

to begin the promote, the target level where the pro- ^ ou t of the DCS into an accessible format by users on the 

mote should terminate, a flag indicating whether it's a WWW. Usually these results would exist in a secure reposi- 

BOM promote, and the version. tory which could only be accessed by WWW users who are 

Send results from External Data Processes to a library. working on the project. This same mechanism can be used 

This utility allows the user to enter the name of a for network access in general, including the extranets, 

Pedigree and the target level and version to which the 2Q intranets, and the internet. In addition to accessing 

Pedigree information should go. information, the ALMs can receive special e-mail requests 

Set up and manage a private library. The utility has fields from users to perform these tasks: 

where the user can specify the name of the library (if Generate various status reports on topics such as PN-EC 

one is to be created), the library path where the reposi- and Design Fix Tracking, Process & Pseudo Process 

tory will reside, the userids of the owners, and either the 25 Results, or BOM information. The DCS would gener- 

userids or authorization groups of those who can access ate the report on the fly and return it to the user's 

it. These properties can be called up for modification at Internet or e-mail address. 

any time. Whenever the owner or access fields are if the user has the proper authority, he can submit e-mail 
altered, the DCS automatically updates the authority requests to add pseudo-process information into the 
records within the Design Control Repository as well as DCS. The contents of the mail would contain a spe- 
the operating system (i.e. AFS) permissions of the cifically formatted command which the DCS can inter- 
directory where the library resides. pre t to set the appropriate results. This could be used by 
Create and monitor a Bill of Materials, The utility offers people remotely connected to a project (such as the 
two modes of operation. In the first, the user identifies chip foundry) to send status information directly to the 
the Bill of Materials, and enters the names of all design 35 DCS. 

components to be added as members. This same utility The DCS permits an authorized user to send commands 

will display any existing information for a BOM, so through the Internet Common Gateway Interface (CGI) 

members can be modified or deleted. For each member, to query information from the DCS or invoke Designer 

the user must indicate whether it's an input, output or Initiated Library Processes (DILPs). 

support member. For an existing BOM, a function 40 Actors & Objects (Section 1.19) 

exists to revalidate all members, but this can only be i n the event of a project where a single large design team 

done by the BOM owner. The second mode builds the or multiple smaller ones, require their data to reside in a 

BOM by reading all the information from an ASC text single repository, the potential exists for a performance 

file written in a prescribed format. This mode can be botdeneck in the Automated Library Machine. The DCS 

used by designers, Data Managers, and third party 45 offers a feature called Actors & Objects to combat this, 

tools. Regardless of how the BOM is created, a newly Actors & Objects allow the Data Manager to define an 

created BOM will result in the valid flags being set for alternate structure in which designers tasks are dispatched to 

all members. The user who creates the BOM using the a p00 l of Automated Library Machines (Actors). No design 

first mode is automatically the owner, whereas the input <j a t a is stored on any of them; they merely execute the tasks 

file used for the second mode contains the owner 50 then store the results and data into the Design Control 

information. Repository (Object). The Data Manager can control the 

View process and pseudo process results. The user sped- types of jobs each Actor is allowed to perform by creating 

fies the design component, data type, level and version. Actor Lists. These lists contain information which the DCS 

He can specify the exact process or obtain a list of all uses to determine which ALM to route a particular job to. 

processes. For each process, the display shows the 55 FIG. 9 shows an Actor/Object environment with four Actors, 

result (if it exists), the date and time it was set, how it Jobs involving the data type of layout and timing are 

was set (library controlled process, external process, or segregated to ALM4. All remaining work is sent to ALMs 1 

manually) and the criteria. These results can only be through 3. The DCS determines which to use based on an 

changed by the Data Manager. mechanism which tries to find either a free ALM or choose 

Associate design problem numbers to design components. 60 one that may be able to spawn a parallel process (assuming 

The designer uses this to pre-associate problem fix the operating system supports it), 

numbers to design components before they are pro- Importing and Tracking Data (Section 1.20) 

moled into the library. This way technical leaders and Internally the DCS tracks all data by component name, 

other designers can determine if a particular problem is data type, level, version, library and most importantly a file 

being worked on. The interface requires the user to 65 reference (fileref) number. These six attributes give every 

identify the component by name and type. Since it's not piece of data in the system a unique identity. In a private 

in the public library yet, it has no level or version. The library, all data is tagged with a DCS identifier as part of the 
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filename, but the identifier may or may not be unique. This the locations for every level of each version. In addition, if 

is because private libraries don't have a concept of levels, he has specific data types that he wishes to further segregate, 

versions or file references. They are merely working areas he can specify a location for them. Finally, the DCS supports 

for the designer, and only require the data to be identified by a feature called Automatic Component Grouping in which 

name and type. The system permits the designers to have 5 a u d a t a types for a given component name will automati- 

multiple copies of a design component by using iteration cal ] y bc located in a subdirectory off of the level directory, 

numbers to distinguish between recent and older data. pjc 10 illustrates a portion of a library directory structure 

However, even though the concepts don't apply, the DCS ^ different levels of storage granularity. LIB_DIR is the 

still assembles an identifier and tags the data. There are two direc(ory for ^ data in ^ Under it> data ^ 

rnethods by which a piece of data can appear into a private M 5y version where vers i on i data resides in the 

ubrarv ' subdirectory VERS1. At this point the diagram illustrates 

1. The designer creates the data from within the private ^ examples of further segregatioa In the VERS1 direc- 
library using some tool (Schematic editor, text editor, tor y m are the schematics and behaviors which comprise 
circuit simulator). level El and E2 for all 3 design components. Although they 

2. The data is created by some tool completely outside of !$ arc physically mixed together, their unique identifiers allow 
the private library, but the designer wishes to import it mc DCS and users to tell them apart. The diagram shows the 
into the library. circuit layouts to be further segregated by data type. So they 

- In either case, the tool' (or user) chooses the- filename: By reside in subdirectory TYPE_LAYOUT Once data reaches ' 

default, this is the design component name. In the first case, level E3, it is segregated by level and type. LEV_E3 

the designer will be asked to specify the data type either 2 o contains all the schematics and behaviors for the E3 level, 

prior to, or during invocation of the tool. In the second case, but the layouts reside in the TYPE_LAYOUT directory 

the user will be prompted for the data type during the import. under LEV_E3 The final example shows data segregated 

In both cases of a data type entry requirement the DCS will on iy by level with no regard to type. This is seen in the 

automatically default the version, level and file reference release level repository LEV_R1 By offering this kind of 

number in order to assemble a uniform identifier code. This 25 flexibility, the DCS permits the Data Manager to group the 

code will be appended to the design component name and da t a in the most advantageous way. In addition, the Data 

will become the new name of the object. Upon promotion Manager could invoke Automatic Component Grouping, 

from a private library into a public library, the DCS will which would result in further subdirectories under VERS1, 

automatically assign a real file reference number to the LEV__E3 and LEV_JU to segregate the pieces by compo- 

object. Based on the destination version, and level, the DCS 30 ne ot name. 

will assemble a new identifier and rename the object accord- Note: This is unnecessary in the TYPE_LAYOUT direc- 

ingly. The file reference number remains the same for the life tories since the only difference between the objects is the 

of the object. As the object traverses through the levels of the component name. In order to boost performance, every time 

library, the level is the only piece of the identifier that a structural change is made to a library which involves 

changes. In addition, the DCS maintains the same identifier 35 repositories, the DCS automatically generates a master cross 

information internally. This is considered the official track- reference between lfcrary/leveWersion/type and physical 

ing information and is always updated first during a promo- location. This table is used by mechanisms such as the 

tion or installation of a new object into a public library. The library search engine to locate data without requiring exteo- 

object renaming is done afterwards. Appending the identifier srve querying of the Design Control Repository. It also 

to the object name serves two purposes: 40 enables library searches to occur in the event the Design 

It increases data security by providing a way for the DCS Control Repository is unavailable. 

to check data integrity during promotions. The infor- Preferred Embodiment for Managing Shared Libararies 

mation contained internally must match the external (2.0) 

identifier at the start of a promote. A mismatch signifies TTie present embodiment provides a controlled enviroo- 
possible tampering of the data outside of the DCS, and 45 ment for the acquisition, movement, disposition and removal 
the Data Manager is alerted to the mismatch. of data from a Data Management System. The embodiment 
It provides an alternate way for a user or another tool is described from the perspective of an overall algorithm 
(such as the library search mechanism) to ascertain the which manages data Libraries. This encompasses not only 
version, level, and data type of an object simply by the storage management issues but the necessary interaction 
looking at it. This contributes to the availability by 50 with a centralized Data Control Repository, 
providing a means to locate and access data even if the Our embodiment covers a broad array of implementations 
Design Control Repository is unavailable (i.e. server ranging from a system whereby the user constantly interacts 
down). with the Data Control Repository to acquire ownership, 
One major advantage to this tracking scheme is it's deposit or move up through the system described in the 
independent of the physical location of the data. The DCS 55 preferred embodiment which incorporates Automated 
permits the Data Manager to establish as many repositories Library Machines (ALM) with a sophisticated file move- 
as he needs down to any level of granularity. For example, ment algorithm. 

all data for a library could reside in one physical directory, The Library Management algorithm serves as the inter- 

the data could be segregated by version only, or there could face between the user and the Data Management system for 

be separate directories for each type of data. This level of 60 routine data control functions. Our preferred embodiment 

flexibility allows the Data Manager to optimize the library to interacts with the Lock and Authority Manager to permit an 

a given environment For example, he can define his reposi- environment which allows multiple users to possess own- 

tories in such a way that the data which moves most often ership in a data object, but ensures only one owner is 

is located on a single volume on his fastest server. Data updating an individual instance at any given time. A Check 

which never moves (i.e. Release Level data) can be located 65 Out utility is provided for the user to request ownership to 

on slow servers or spread out over multiple servers. As the a piece of data, transfer ownership, or take ownership if they 

Data Manager defines his library structure, he can specify are an authorized surrogate of the current owner. Likewise, 
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a utility exists to perform data deletion in a safe and algorithm permits the user to precheck a work request 

controlled manner by ensuring only authorized Data Man- interactively prior to the request being sent to the ALM. This 

agers or valid data owners delete their own data without feature ensures the work request will complete successfully 

jeopardizing any other data. by running all the same checks which are normally run by 

An integral part of library Management is establishment 5 the ALM prior to data movement. Since our embodiment 

of private and public libraries. Often these public libraries permits the user to request a promote through multiple levels 

are shared by many users which can create data integrity with a single invocation, this pre-qualification feature can 

exposures if data is not properly stored into and moved greatly improve productivity. 

through a public library. The overall algorithm manages the In order to maximize throughput of large data volumes, 

movement of the data between the actual physical locations to our Library Management Algorithm employs Automated 

specified under the established library structure. Since our Library Machines to act as independent agents for the user 

embodiment permits data to reside across different computer community. These ALMs are service machines which use a 

platforms, the algorithm contains functions for handling virtual queue to accept work requests from users and per- 

cross-platform data transfers. Although our Library Man- form Library or non-Library functions. The ALMs interface 

agement algorithm only requires a simple promotion algo- is directly with the Data Control Repository through dedicated 

rithm in order to function, the present embodiment reveals high speed ports in the Communication Manager. They can 

a highly sophisticated File Movement Algorithm. exist on clients, servers and on different computer platforms. 

" " lightly loaded Data Management Systems can usually Our preferred embodiment" describes three basic cohfigura- 

support execution of the above Library Management tunc- tions which permit the ALMs to perform any of the services 

tions in the client's environment where the user calls upon 20 requested by the Library Manager algorithm. The basic 

the Data Control Repository to initiate the function, and the configuration is known as a Conventional system where a 

repository immediately invokes the appropriate algorithm or single ALM accepts all work requests and handles all 

utility. However, in large enterprises, this can lead to unna- services for the Library Manager, including any Automated 

ceptable performance degradation as many users simulta- Library Processing. The second configuration is Remote 

neously access the repository. Therefore, our Library Man- 25 Execution Machines which is an extension of the Conven- 

agement algorithm is capable of supporting Automated tional system. Here, a single ALM receives all work requests 

Library Machines arranged in a variety of configurations to from the user, and processes all promotion, installation, 

optimize performance. The use of ALMs also permit Auto- movement, and removal of data. However, additional ALMs 

mated Library Processing to occur. The Library Manager may exist to perform Automated Library Processing. The 

incorporates routines for properly installing any output 30 ALMs interact with the Library Manager, Communication 

created by an Automated Library Process into the DMS. Manager and Promotion Algorithm to dispatch any desired 

Finally, the Library Manager provides instant notification library processing to a Remote Execution Machine, which 

to the user for any service rendered This occurs whether the executes the task and returns the results to the master ALM. 

task is executed in the user's environment or remotely on an The most powerful configuration is known Actor/Objects 

Automated Library Machine. In the event a task fails to 35 and this arrangement employs a pool of ALMs which serve 

complete, error messages explain the problem. Successful as general purpose machines. They can perform any desired 

operations also result in notification thus ensuring users Library Management function, including Automated Library 

possess situational awareness of their data at all times. Processing. They can even interface with Remote Execution 

Our preferred embodiment describes a File Movement Machines to provide an environment with both general 

Algorithm which interfaces with other Managers in the 40 purpose machines and dedicated service machines. Each 

overall Data Management System. This provides a great ALM can be programmed by the Data Manager to define the 

degree of data security while offering a plethora of auto- type of work requests it can process. This arrangement even 

mated features. The Promotion Algorithm interacts with the includes a special Dispatcher ALM whose sole purpose is to 

Authority and Lock Managers to ensure that users transfer dispatch user work requests to the next available Actor 

data that they own from a private library into a public shared 45 machine. 

library. Furthermore, only authorized users may promote the Automated Library Machines are special purpose Auto- 
data through the various library levels. Reader service machines which means they are capable of 

Upon initiating a promote request, the algorithm com- performing virtually any software task that can be invoked 

pares any recorded process results against pre-defined pro- from a command line. These tasks can be completely 

motion criteria to ensure that only data which meets a quality 50 independent of the Data Management System which permits 

standard may be elevated to the next level. The promotion an ALM to play multiple roles in a business environment. It 

algorithm offers a flexible means of promoting large vol- can literally be processing a Data Management request one 

umesofdata including features which handle heterogeneous minute, and formatting a word processing document for 

tapes of data from different levels and versions within the printing the next minute. The underlying AutoReader 

same request. Interaction with the Aggregation Manager 55 mechanism incorporates features to enable automatic recov- 

allows fast and efficient Bill of Material (BOM) promotes. ery in the event of a system crash. The Library Manager 

The promotion algorithm also works in conjunction with further enhances this by adding automatic retry of aborted 

the Problem Fix and Release Manager to apply problem fix library operations due to system problems, 

tracking, incremental change, part number and release con- File Promotion Process 

trol to any desired piece of data moving through the Data 60 The present embodiment incorporates a robust process for 
Management System. This includes interaction with the user promoting data from a private library into a shared public 
to gather the appropriate information at promotion time as library as well as moving data through a shared public 
well as background checking to safeguard against data library. Although it's especially suited to interact with Auto- 
integrity violations such as a single part being associated mated Library Machines and the other algorithms described 
with two different releases. 65 in the other sections of the Preferred embodiment, this 
For environments such as preferred embodiment, which process does not require any of those elements to be present 
incorporate Automated Library Machines, our promotion in the Data Management System (DMS). 
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Id order to track data properly, our embodiment provides 
a conduit for data to enter, and travel through, the DMS ia 
a safe and controlled manner. This ensures that all data is 
subjected to the proper checks regardless of the point of 
origin or final destination. The preferred embodiment 
depicts the overall flow of the promote, or data transfer, in 
FIG. 12. 

The flow begins with Step 22101 in FIG. 12 in which the 
user is presented with the Promotion Screen. FIG. 13 shows 
this screen, which permits the user to enter information 
about the file(s) they wish to process. Promotion can entail 
transferring data from the user's private library to a pub He 
library or moving data within a public library. 

Turning our attention to FIG. 13 we see the promotion 
screen which consists of data entry fields 22201 through 
22208. A single screen is used to either Put a file from a 
private library into the DMS or Promote a file from one level 
of the DMS to another. The type of action is determined by 
trie user supplied'informationr 

The preferred embodiment presents the user screen in a 
graphical environment where the user engages pull down 
menus, pop-up menus, drop-down lists, radio buttons, push 
buttons, fill-in fields, and mouse interaction. It should be 
noted, however, that all functions discussed further in the 
preferred embodiment can be implemented using simple text 
screens, or more advanced data entry systems such as touch 
screens, voice commands or 3-D graphics. The preferred 
embodiment depicts the method most conducive to the 
Motif™, Windows™, and OS/2™ application environ- 
ments. 

Field 22201 holds the name of the file to be promoted. If 30 
a single file is being promoted, the name is typed in directly. 
If the user desires a selection list, it is automatically invoked 
by simply leaving the field blank and completing the remain- 
der of the form. Upon hitting Enter, a library search would 
be employed to obtain a selection list of files. The third 
method is to promote a group of files via a text-based list, 
edited in advance, in a prescribed format. This is covered 
below in the explanation of user options. 

Fields 22202 and 22203 allow the user to enter the 
Version and Library File Type respectively. In the preferred 
embodiment a promotion is not permitted across versions 
nor can a file type change as a result of a promote. 

Fields 22204 and 22205 convey the Source Library and 
Level information. In the case of a Put, the Source Library 
can be any valid private library in the DMS. The Level 
would default to User, but a valid entry level, name can be 
entered. Field 22204 can also be the name of a public horary. 
In this case, field 22205 would contain the starting level for 
the Promote. Each field has a "smart" drop down menu 
button associated with it. The Library button next to field 
22204 displays a list of all public libraries in the DMS plus 
all private libraries owned by the user. The button next to 
field 22205 displays all valid levels for the library entered 
in field 22204. 

Fields 22206 through 22208 are almost identical to fields 
22204 thru 22205, represent the Destination information. 
Field 22206 is the destination library which is frequently the 
name of a public library. As with field 22204, the drop down 
menu button next to field 22206 displays all libraries in the 
DMS. However, our embodiment also permits a private 
library owned by the user to be a valid entry. In this case, 
fields 22207 and 22208 default to User, but can be changed 
to the valid level names, and none of the options at the 
bottom of the screen apply. The resulting operation would be 
a simple file copy from the source private library to the 
destination private library, with the file being named accord- 
ing to the Destination Level information. 
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Returning to the general case, if field 22206 contains a 
public library then the user would fill in the destination level 
in field 22207. Once filled in, field 22208 automatically 
takes on the same value. In the case of a simple Put, field 
22207 represents the final destination and is equivalent to 
the Destination Entry Level in field 22208. For a Put with 
Promote, field 22207 represents the destination level while 
field 22208 denotes the doorway through which the file 
should enter the DMS. Finally, in the case of a Promote, field 

22207 again represents the Destination Level and field 

22208 is ignored. 

Turning our attention to the lower portion of the screen, 
we see two sets of push buttons. The first set, 22209, 
represent user options that pertain to any type of Put or 
Promote. Any number of these options can be invoked and 
they are defined as follows: 
Via List The list of files to be processed will be read from 
a text based file. The user is presented with a dialog box 
requesting the name of the file. The names of the files 
will be read from this list, but all other information will 
be taken from fields 22202 through 22210. 
Foreground Checking Pre-checks the data using the same 
checks that will take place during the background 
portion of the promotion. This allows the user to test the 
promote and ensure everything will work before the 
request is submitted to the DMS. 
Via Copy is normally active for most environments. It 
enables the DMS to use a file copy operation as the 
preferred method for transferring data from the source 
to the destination. In certain environments, this may not 
be possible or desirable, so deselecting this option 
forces the data to be "sent" from the source to thie 
destination. 

Reset Update Lock is the means by which the user 
informs the DMS to remove any existing Update Lock 
from the file(s) and leave them in an unowned state at 
the completion of the promote! 

High Priority Tells the DMS to process this request next 
assuming it's the only high priority item in the queue. 
If there are multiple requests with this priority, they are 
processed in FIFO order. 

Override Process Parms Allows the user to add or modify 
the parameter passed to an underlying library process. 

The last set of buttons is set 22210 which represent 
options only available during a Promote. This is because 
these options only pertain to data already under control of a 
DMS. Any number of them can be selected and they are: 

BOM Promote Indicates the user wants the Bill of Mate- 
rials associated with the file entered in field 22201 to be 
promoted. If the file doesn't have a BOM associated 
with it, the promote will fail. 

Anchor Only Indicates to the DMS to only promote the 
anchor file of the BOM associated with the file entered 
in field 22201, but leave the members at their current 
locations. 

Retain Source is usually "off" which enables the DMS to 
move the file from the source location to the destina- 
tion. However, in certain environments it may be 
desirable to leave a copy of the file at the source 
location after the promote is completed, so this option 
exists for this purpose. 
Returning to the overall flowchart in FIG. 12, information 
entered in Step 22101 is now passed to Step 22102, Fore- 
ground Processing. The detailed algorithm for processing 
promotion requests in the foreground is described in FIGS. 
14a thru 14/ It begins with Step 22311 of FIG. 14a, Parse 
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Opts. Here all the information entered in Step 22101 is This information includes a flag indicating whether the 

checked for validity. The following cases are examined: candidate file is the master file of a file group, and if so, the 

If the Source and Destination Libraries are private list of Library File Types associated with that file group. By 

libraries, then the Source and Destination Levels are definition, all members of a file group snare the same file 

allowed to be any combination of User and valid public 5 name, library, version and level. 

levels. The user must have edit authority to the Desti- Step 22317 reviews the information returned in Step 

nation private horary. This results in a simple file copy 22316 to see if a File Group Exists If so, the program 

with the name being adjusted according to the Desti- continues with Step 22318. Otherwise, it branches to Step 

nation level field. 22321. Steps 2231^-22320 pertain to processing file groups. 

If the Source Library is a private library and the Desti- 10 i n step 22318 the program checks for the existence of any 

nation Library is public, then the following conditions Required Members of the File Group. These are denoted in 

must be met: information returned in Step 22316. If a required mem- 

1. If the Source Level is User then the DesUnation bef ^ ^ found k (he vgef% priva(e 1Jbrary> an enor 
Entry Level must be a valid entry point. The Desti- message ^ and the promote is terminated. If an 
nation Uvel must be the same or higher ^ mcmbcr docsn , t exis a ^ ^ ^ {Q mc 

2. If the Source L*vel is a valid entry point, Jhenthe ^ promotion continues. 

Destination Entry Level must be identical. The Des- rT ^ " , ~ , a 
tination Level can be the same or higher. SlC ^ 2 ^^™^^ ^ Op^hosc flag was 
If the Destination and Destination Entry Levels are the ■* ™ Step 22311. If it's true, then the locks on the all 
same, this classifies as a simple put. If the Destination Level costing subordmate files are examined, in Step 22320, Fig 
is higher, it's a combined Put with Promote. 20 Locks, to ensure the user either owns the Update lock or is 
Ifthe Source Library is a valid pubhc Ubrary, and the level * surrogate for the owner. In addition, it ensures no other 
is a valid level, then the Destination Library must be the tyP* of lock exists which would prevent the Put. Such an 
same as the Source Library and the level must be higher example would be an Overlay lock at the entry level. If the 
than the Source LeveL These conditions signify a user is not the owner, our Lock Manager will Update Locks. 
Promote In this case the Destination Entry Level is 25 In our preferred embodiment, our embodiment maintains 
ignored. absolute data integrity by adhering to the lbllowing rule. The 
Any other combinations of those fields is considered an Foreground Check option, available to the user on the 
error condition and the promote terminates. In addition, the promotion screen in FIG. 13 only pertains to the foreground 
options are examined to set various flags which will be used processing of the promote. It is ignored in the background, 
to determine branching later in the algorithm. 30 where full checking is done at all times. The option serves 
Step 22312, Input Files follows Step 22311. Here, FIG. merely as a performance enhancement which allows the user 
13, entry field 22371, Name is examined for three possible to submit promotion requests with minimal checking. The 
responses. The simplest case is the name of a single file advantage of the Check option is that an error free fore- 
which implies only this file is to be promoted. Second, is a ground session practically guarantees a successful promote 
blank or some other keyword in which the user requests a 35 in the background. However, depending on the environment 
library search of all files of the specified Library File Type and the implementation, the trade-off may be lengthy pro- 
starting at the specified Source Library, Level and Version. cessing time on the client machine. For these situations, our 
If any of these fields are invalid or missing, the user is embodiment offers the user the option of bypassing a series 
prompted to enter the information. The standard Library of foreground checks and "taking their chances" on the 
Search manager is invoked to perform this task. At the 40 promote processing successfully in the background, 
completion of the search, the user is presented with a Steps 22321 and 22323 can be processed in either order, 
selection list of all files found. One or more files can be and they are used as decision points for Steps 22322 and 
selected for promotion. The third possibility is that the 22324 respectively. In Step 22321, the program inspects the 
ViaList user option in button field 22379 of FIG. 13 has been Fix Management information for the package. If the package 
selected. This indicates that the user wants the foreground 45 is under Single Fix Mode or Engineering Change Mode, 
process to extract the names of the files from a text file. The then the LFT FM, or Library File Type Fix Management, 
user is prompted for the name of the file which lists the flag is examined for the LFT being processed. If the flag is 
names of the files to process. All other information, besides on, Step 22322 is invoked, otherwise the program proceeds 
the file name, is taken from the main screen. to Step 22323. In Step 22322, FM Assoc, the program 
Once the input file(s) are determined, the algorithm enters 50 attempts to associate the file being processed with a Problem 
the File Loop in Step 22314. For the simple case of a single Fix Number. If the package is under Single Fix Mode, the 
file being promoted, this loop is only exercised once. In the default Problem Fix Number is associated to the file. If the 
cases where a selection list or text file was used to provide package is in Engineering Change Mode and the repository 
a list of data to promote, all Steps between 22313 and 22347 already has existing Fix Numbers for that file, they are 
are executed for each file. 55 presented on a user screen. This is usually done with another 
Step 22315 asks the question "is this a Put or Promote?" interrogation of the Control Repository. The user is given the 
The answer to this question determines which way the choice of selecting one of the existing numbers or entering 
program must branch. A Put refers to data entering a public a new one. If no Fix Numbers exist, the user is prompted to 
library from a private library whereas a Promote refers to enter a new one. 

data moving through a pubhc library. Our embodiment 60 In Step 22323, the program checks to see if the Part 

permits a Put followed by a Promote in the same request, but Number Control Level is being crossed by comparing it to 

for purposes of resolving Step 22315, that request is treated the Destination Level provided by the user in Step 22301. If 

like a simple Put. All Promotes continue to Step 22326 in the answer is "yes", then the LFT PN, or Library File Type 

FIG. 14c while Puts branch to Step 22316, Fig Info in FIG. Part Number, flag is examined for each LFT being pro- 

145, 65 cessed. If the flag is on, Step 22324 is invoked, otherwise the 

In Step 22316 of FIG. 14b, the program requests any program proceeds to Step 22325. In Step 22324, PN Assoc, 

Automatic File Group relative to the file being promoted. the program attempts to associate the file being processed 
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with a Part Number. If the repository already has an existing 
Part Number for that file, it is presented on a user screen. 
This is usually done with another interrogation of the 
Control Repository. The user is given the choice of selecting 
the existing PN or entering a new one. If no Part Number 5 
exists, the user is prompted to select a new one. 

Since Steps 22321 through 22324 may be repeated for a 
large number of files, the Design Control System may be 
implemented in such a way that the DMS server returns all 
associated Part Number and Fix Management data for all 10 
files being processed with one large query. The client then 
sifts through the data to find the information necessary to 
interact with the user. The algorithm states the information 
that must be obtained from the Control Repository and the 
user, but permits a great deal of flexibility in the way it is 15 
acquired. 

At this point the algorithm continues with Step 22325, 
Dest-Entry in FIG. 14d In this step, the code determines if 
this is a simple Put or a Put/Promote combination by 
comparing the Destination Entry Level with the Destination 20 
Level. If they are the same, it's considered a simple Put, In 
this case the code proceeds to Step 22319. If the Target Level 
is higher than the Entry Level, it's considered a Put with 
Promote and continues to Step 22332. 

Returning to the Put/Prom decision in Step 22315, if the 25 
user is requesting a promote, the code branches to Step 
22326 in FIG. 14c. Here the control repository is queried to 
rind out whether the file being promoted is the anchor file to 
a Bill of Materials (BOM). Regardless of the outcome, the 
Model Option flag in Step 22327 is examined. The answer 30 
to both questions yield four possibilities. If both answers are 
"yes" or both answers are "no" this is the normal case in 
which the algorithm proceeds to Step 22330. If the file is a 
BOM, but the BOM Promote Option was not specified in 
Step 22301, the Anchor Only Option flag in Step 22328 is 35 
examined. If this flag is on, then the user is requesting to 
promote only the anchor file and not the entire BOM. If the 
flag is off, a warning is presented to the user requesting that 
either the BOM Promote or Anchor Only Option must be 
selected. Finally, if the file is not a BOM, but the user 40 
specifies the BOM Promote Option, an error message is 
displayed and the program terminates. 

Continuing with Step 22330, the program checks to see if 
a BOM exists at any of the levels being promoted through 
with the same name as the file. If so, a warning is issued, in 45 
Step 22329, to the user indicating a BOM will be and 
subsequently deleted if the promote continues. The user is 
given the option to continue or abort the operation. If no 
BOM Overlay is imminent, or the user accepts the overlay, 
the algorithm proceeds to Step 22332 of FIG. 14cL 50 

In Step 22332, Chk Lvl Order, the promotion path is 
examined to ensure a legal path exists from the Source Level 
to the Destination Level. In the case of a Put, where the 
Destination Level is not equal to the Entry Level in Step 
22325, the Entry Level is also checked to ensure it's part of 55 
the path. If not, an error is displayed and the program 
terminates. Step 22333 is a Level Loop which must be set up 
so Steps 22334 and 22335 can be performed for each level 
in the promotion path. 

Step 22334, EC LVL, is where the program checks to see 60 
if the EC Level is being crossed during the transport This is 
done by determining if the Destination Level entered in step 
22301 is at or above the EC Control Level. If the test 
resolves to a "yes" answer, the program must perform step 
22335, EC Assoc. Here it queries the Control Repository for 65 
EC information regarding any Problem Fix Numbers and 
Part Numbers selected or entered in steps 22322 and 22324. 
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For any Fix Number or Part Number not associated with an 
EC, the program prompts the user to select an EC from a list 
of existing EC Numbers or choose a new one. 

Upon completing the loop, the Check Option flag in Step 
22319 is examined again. If this flag is off, the program 
proceeds to Step 22345 in FIG. 14/ Otherwise, if the user 
requests the option, the Level Loop in Step 22333 is again 
invoked. Step 22337, Lock Check is performed to ensure no 
locks exist against the file, at any of the levels being 
traversed. These include Update, Move, Overlay and Pro- 
cessing locks. If Update locks exist, the user must either be 
an owner or a surrogate of the owner. In the latter case, the 
user is given the opportunity to reset the lock, upon which 
notification would be sent to the current owner. 

In Step 22338, the User's Authority is checked to ensure 
they can promote the file to that level. Finally, in Step 22339, 
a complete BOM Invalidation check is performed. There are 
two forms of this check. In the simplest case, the file is not 
a BOM, so the control repository is examined to see if any 
other BOMs will be invalidated by the movement of this file 
to the Destination Level. In the more complex case, the file 
is a BOM. Here the same check is made as in the simple 
case, but additional checks must be made for every member 
of the BOM to determine if their movement will invalidate 
any other BOM. In either case, the results of the pending 
invalidation are displayed for the user to examine, using our 
Aggregate Manager for this check, as BOMs may have 
many members. 

It should be noted that the order of Steps 22337 through 
22339 is not critical and is combined into single large 
queries in our preferred embodiment. Files being promoted 
from a Private Library into a Public Library employ the 
QRSUPGET function, while promotions within the Public 
Library utilize the QRSUPCHK routine, described in FIG. 
16. Upon completion of these checks for each level, the 
program moves on to Step 22340 to ensure the File Exists 
This not only means the file physically exists with the proper 
nomenclature in the directory corresponding to the Source 
Level, Package, Version and Library File Type, but this also 
means the control repository agrees that the file exists in that 
location. If for example, the user believes the file is at Level 
A, but the control repository is tracking it at Level B, this is 
a data integrity violation and the promote ceases. 

At this point, the algorithm proceeds to Step 22341 in 
FIG. X4e, where the question "is it a simple Promote'* is 
asked. If so, Step 22342, Crichk is performed. For a pro- 
motion beginning at a library level (not one that is chained 
to a Put), the control repository is queried for any Fost- 
Processes or DILPs defined at the Source Level. If there are 
any processes, then the process results for the file being 
promoted are examined to ensure they meet the proper 
promotion criteria. If any fail criteria, a warning is issued 
informing the user that the promotion will fail. 

Next, Step 22326 is executed again to check if the file ;s 
a BOM. If so, a Member Loop is set up in Step 22343 where 
each member has their process results checked against any 
Post-Processes or DILPs which exist for those LFTs at the 
Source Level. This checking is the same as Step 22342. 

If the answer to the Promote question in Step 22341 or the 
BOM test in Step 22326 is "no" the code proceeds to Step 

22345. Likewise if the Member Loop in Step 22343 was 
exercised, the code proceeds upon exit to Step 22345 in FIG. 
I4f. In Step 22345, Fproc Option flag is examined to see if 
the user is bypassing Foreground Processing. If the flag is 
off, the code returns to the top of the File Loop in Step 
22314. If the flag is on, the Level Loop in Step 22333 is 
initiated again. For each level that the file will pass thru, Step 

22346, Fproc will be called. 
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In the Fproc step the code queries the control repository 
for all foreground processes defined for that Library File 
Type at that level, version and package. Each process is then 
executed immediately in sequence so the user can enter the 
appropriate responses. These foreground processes are 
established by the Data Manager. Upon completion of the 
Level Loop, the code returns to the File Loop in Step 22314 
of FIG. 14a Once Steps 22314 thru 22346 are executed for 
all files in the promote request, the algorithm proceeds to 
Step 22347, Override Option. 

In Step 22347, the Override Option flag is examined. If 
it's off, the program proceeds to Step 22349. If it's on, then 
Step 22348, Override is executed. In this step the user is 
allowed to override any of the process parameters for the 
library processes that will be executed during the promotion. 
The algorithm queries the control repository for all Pre and 
Post-Processes defined for this Library File Type at this 
* level, version and package. All of the process parameters are 
displayed on the screen, and the user can select and modify 
as many as desired. Once finished, the user "OK"s the 
modifications, and they are written into the control infor- 
mation which is used in the next step. The DMS will use 
these modified parameters to drive the library process, only 
if they exist. Otherwise it defaults to using those define by 
the Data Manager. 

In step 22349, Xmit, the program gathers and transmits all 
of the necessary data to the Design Control System. In our 
preferred embodiment, the destination would be an Auto- 
mated Library Machine which would access most of the 
information via a "copy" operation. The following types of 
information need to be transmitted: 
The type of request: Put, Promote, or Mixed 
The list of files being promoted. The following informa- 
tion must exist for each file in the list: 
The Filename 
The Library File Type 
The Package 
The Version 

The Source Level, Entry level, Destination Level 
Fix Numbers (if any) 
Part Numbers (if any) 
EC number (if any) 
Any user selected options that pertain to the background 
operation. 

The user's electronic id or e-mail address. 
Information gathered during any foreground processing 
that occurred. 

Information relating to any process parameters altered 
during the Override operation. 

In addition, for Put operations the riles themselves must 
be transferred from the user's private library. This includes 
all existing members of Automatic File Groups. Our pre- 
ferred embodiment performs this by either having the Auto- 
mated Library Machine copy the files or by sending them. 
The detennination is made based on a user option called Via 
Copy which exists on the main input menu in FIG. 13. One 
other option on the main menu is the Emergency option 
which informs the DMS to treat this as the highest priority 
in the processing queue. This feature enables critical work to 
be processed ahead of older jobs. 

Returning to FIG. 12, the algorithm proceeds with the 
Background processing in Step 22103. In our preferred 
embodiment, the promote request from Step 22102, Fore- 
ground is transmitted to an Automated Library Machine 
(ALM) for processing. The first step is for the ALM to Read 
Control Information which is done in Step 22411 of FIG. 
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15a. Here, the names of files in the promote request are 
stored into a data structure along with all pertinent control 
information like Problem Fix numbers, Part Numbers, EC 
Numbers, Entry Level & Destination Level for each file, and 
the user options. The options are further parsed to set flags. 
In our preferred embodiment, these requests are homog- 
enous which means all files in the request move from the 
same source to the same destination. Since the Foreground 
step determined the type of request, it's contained in the 
control information and used to set the flag which is exam- 
ined in Step 22413. 

However, our embodiment also supports heterogeneous 
file movement. An example of this is two files where one 
moves from level A to B while the other moves from level 
15 C to D. Although this request can't be generated by the 
Foreground process in Step 22102, it can be created by 3rd 
party tools interfacing with the DMS. To accommodate this, 
the control file indicates' the type* of request as Mixed In this ' 
case, Step 22413 must employ the same algorithm used in 
the Input Files step of FIG. 14a to determine if the request 
is a Put or Promote on a file-by-file basis. Since the control 
information contains the Source, Destination and Entry 
Level for each file, this is quite easily done. At this point, the 
File Loop in Step 22412 is entered in order to execute Steps 
22414 thru 22418 on each file in the request. Step 22413 
checks to see whether the request is a Put, Promote, or 
Mixed where: 

Put means all files in the request are being promoted from 
a private library into the same level of a shared public 
library. The files may have to be promoted one or more 
times to reach the destination, but all files will travel the 
same path. 

Promote means all files in the request are being promoted 
from one level of a shared public library to another. The 
files may have to be promoted one or more times to 
reach the destination, but all files will travel the same 
path. 

Mixed means the request contains a mixture of files where 
2 or more files may travel different paths. In this case 
the background algorithm must determine the promo- 
tion path for each individual file. 
Note: Our preferred embodiment does not allow this 
type of request to be generated from the Foreground 
user interface, but 3rd party tools may create one. 
In the case of a Promote (ie. the file is being moved from 
one level of the DMS to a higher level), Step 22414 is 
employed to set an Overlay Lock on the file. The DMS uses 
this Overlay Lock to prevent a different ALM from moving 
the same file while tins request is in progress. Next, Step 
22415, Promote Check is called upon to do the following 
checks: 

Ensure that the Source Level is valid and not a frozen 

Release Level. 
Ensure that a valid path exists from Source Level to the 

Destination Level. 
Determine the next higher level above the Source Level. 
(This may not be the Destination Level if this is a 
multi-level promote). 
Obtain the physical location of the Source and Destination 
Levels. 

Ensure the user is authorized to do this promote. For 
regular promotes, the user must have normal promote 
authority whereas for BOM promotes, Model Promote 
authority is required. 
Ensure the file really exists in the DMS at the expected 
Source Level. 
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Check for any Processing or Move locks. Also look for 

any Overlay Locks at the next level. 
Check all Post-Process and DILP criteria at the Source 
Level to ensure the file meets all of the criteria. In the 
case of a Bill of Materials (BOM) promote, each 
member of the BOM is also checked to ensure all 
criteria is met. 
If the file is crossing the EC Control Level, and the file is 
under Problem Fix Management, check to ensure a 
proper EC number is provided. 
If a BOM Promote is requested, a check is made to ensure 

a BOM is associated with the file being processed. 
If a processing lock is detected, the promote request is 
recycled back into the DMS queue to await completion of 
the library process. 

Note: If a processing lock exists, special hang detect code 
is used to determine if the file has been locked for an 
unusually long period of time. If so, the user is notified and 
advised to check on the process job. 

Returning to Step 22413, if the request is a Put, men Step 
22416 in FIG. 15 is employed to see if Update Locks Exist 
in the user's name, at the Destination Entry Level, for the file 
being processed. If not, one is acquired in Step 22417, Updt 
Lock. This lock may be permanent or temporary depending 
on the setting of a user controlled option which is discussed 
later. The reason for setting it at this time is to prevent 
someone from taking ownership of the file while the Put is 
in progress. 

In Step 22418, Put Checks, a scries of checks are per- 
formed against the file. Many of these are duplicates of those 
run in the Foreground in Step 22102, if the user specified the 
Check option during Step 22101. In our preferred 
embodiment, these checks are all done with a single query 
to the Control Repository. The following are performed: 

A check is made to ensure no Processing, Move or 
Overlay locks exist on the file. 

Ensures the "user is authorized to Put this file to the Entry 
Level. 

The physical location of the Entry Level and Source Level 
are acquired. 

The File Reference number is generated. 

The Lock Reference number is acquired. 

The Entry Level is checked to ensure it's a valid entry 
point into the DMS. It may be a Sideways Release 
Level, but not a regular Release Level. 

If any of the checks fail, the promotion terminates with an 
appropriate error message. 

At this point the File Loop in Step 22412 is repeated until 
all files are exhausted. Upon exit from the loop, control 
proceeds to Step 22419, List Files. Here, the file information 
is re-written with the source and destination physical loca- 
tions in preparation for the upcoming file transfer. The file 
name of this control file indicates whether the file transfer 
pertains to a Put or Promote. 

Upon completion of List Files, the Pre-Processing Done 
flag is examined in Step 22420 of FIG. 15c. The flag is set 
to "Done" if no Pre-Processing is required, or whenever the 
Process Manager completes all required PreProcesses. If the 
answer is "no", then the Process Manager, in Step 22421, is 
employed to run any pre-processes that exist. The Process 
Manager processes all files in the list with a single invoca- 
tion using the control file generated in Step 22419. If any of 
the pre-processing fails, the promotion with an appropriate 
error message. At the completion of the Pre-Processing, the 
Preprocessing flag is set, and the Process Queue in Step 
22422 is interrogated. Although the processing completed in 
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Step 22421, it may have required work to be dispatched to 
other ALMs. In this situation, the DMS maintains data 
integrity by setting a Processing lock in the Process Queue. 
If the current ALM detects an outstanding bck in Step 

5 22422, on the file being processed, it will recycle the 
promote request until the lock is cleared. This ensures that 
the order of execution for library processes is always main- 
tained regardless of the distribution of workload. 
Continuing with Step 22423, a special option flag denoted 

10 Nogo is checked. If it's set, the promotion terminates 
successfully even though no files were actually transferred. 
This is a mechanism the DMS uses to initiate library 
processing against a transient file which doesn't need to be 
permanently retained. For example, a transaction file may be 

15 promoted into the DMS for the sole purpose of initiating a 
library process to update a master file residing in the library. 
Once the master file is updated, the transaction file is no 
longer necessary so it can be discarded. In this case, the 
Nogo option terminates the Put without wasting time trans- 

20 ferring and deleting the file. If the Nogo option doesn't exist, 
control proceeds with another File Loop. 

Once again, Step 22412 is invoked to loop through all 
files in the request In addition, Step 22413 is used to 
determine if this is a Put or Promote. In the case of a Put, 

25 Step 22424, Sup Put is exercised. In our preferred 
embodiment, this is performed via the QRSUPPUT routine, 
which is responsible for updating all the necessary tables to 
indicate that the file now resides in the new Entry Level 
location. In addition, the Control Repository examines the 

30 Fix Management and Part Number flags for the current 
Package, File Type, Version, and Level (PFVL). It also 
checks to see if the EC or Part Number Control Levels are 
being crossed. Depending on the results of these flags and 
levels, it expects the corresponding Problem Fix numbers, 

35 Part Number and/or EC Number to be available. This 
information was gathered during Step 22102, Foreground 
Process The DMS updates all tables associated with Prob- 
lem Fix Management and Part Number control at this time. 
If the file is overlaying an older version of the same file, the 

40 Problem Fix numbers from the old file are appended to those 
of the new file. Any previous iteration of the file, at a higher 
level, with the same Problem Fix Numbers as the file being 
promoted will result in the higher level Problem Fix Num- 
bers being Superseded Also, the locations of the File Group 

45 subordinate files are updated. If this query completes 
successfully, the file is officially promoted into the DMS, 
even though the file hasn't physically been transferred yet. 
In order to maintain absolute data integrity, the DMS always 
has the correct information. If a file physically resides in a 

50 state other than that reported by the DMS using a query, the 
file is in error and needs to be rectified. 

If Step 22413 determines the request is a Promote, Step 
22425, Sup Prom is invoked. In our preferred embodiment, 
this is a accomplished by the QRSUPPRM routine, which is 

55 responsible for updating all the necessary tables to indicate 
that the file and all File Group subordinate files now reside 
at the level above the Source Level. For BOM promotes, the 
tables for all member files previously at the Source Level are 
updated as well. Members currently at the Destination Level 

60 or higher, or members in other libraries, will not be affected. 
In addition, the Control Repository examines the Part Num- 
ber flag for the current Package, Version, Level and LFT. If 
it exists, and the Part Number Control Level is being 
crossed, it expects the corresponding Part Number to be 

65 available. Likewise, the DMS checks to see if the EC Level 
is being crossed, and if so, the appropriate EC Number must 
be present. This information was gathered during Step 
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22102, Foreground Process The DMS updates all tables 
associated with Problem Fix Management by appending any 
new Problem Fix Numbers to any existing numbers pertain- 
ing to the previous iteration of the file. Any previous 
iteration at a higher level with the same Problem Fix 
Numbers as the file being promoted, will result in the higher 
level Problem Fix Numbers being Superseded Subsequently, 
the DMS attaches all Problem Fix Numbers for this file to 
the EC Number. Also, the Part Number tables are updated, 
as necessary. 

At this point control proceeds to FIG. ISd where various 
flags must be checked, and possible additional actions taken. 
In Step 22426, BOM Ovly, the Sup Put or Sup Prom return 
code is checked for an indicator that an existing BOM was 
overlaid by this promotion. If so, then Step 22427, Send Msg 
is invoked to send a message to the owner of the BOM 
informing them of the BOM eradication. Next, Step 22428, 
Erase Toll Fig is invoked to check if a file group exists for 
the file being promoted. If so, and the Erase-To-Level flag is 
set, then Step 22429, Erase Fig is invoked. Here, the 
program determines whether the subordinate file will be 
replaced by an incoming file. If not, the existing subordinate 
file is erased and a message is sent to the owner informing 
them of the file removal. 

In Step 22430, the BOM Invalidate flag is checked. This 
indicates that the promotion of this file caused one or more 
BOMs somewhere in the DMS to be invalidated. This would 
happen if this file is a member of some other BOM. A 
sophisticated algorithm exists in the DMS to quickly check 
all BOMs in the system for the presence of this file. If an 
invalidation occurs, Step 22431 is invoked to Notify BOM 
Owners exactly which BOM was invalidated and which file 
caused the invalidation. It should be noted that Steps 22426 
and 22428 and 22430 can be checked in any order. 

The algorithm continues with Step 22432, Move Files. 
The method for moving data is very dependent upon several 
factors. These include the system environment, the existence 
and/or arrangement of Automated Library Machines, and the 
user options selected during initiation of the Put or Promote. 
If no ALMs exist in the DMS, it's assumed that the user's 
client environment has the proper read and write access to 
the data repositories. The code uses the appropriate combi- 
nation of copy, delete and/or rename commands to accom- 
plish the desired Move operation. However, if ALMs are 
employed, a Move algorithm is used to determine how this 
step is implemented. This algorithm is discussed in more 
detail below. For the moment it's assumed that a method is 
in place to copy, delete, and/or rename files throughout the 
entire DMS. 

In our preferred embodiment Step 22432 is usually done 
with a file copy for a Put operation, but the system does 
support an environment where files can be sent, or otherwise 
transmitted. To accommodate this, a special option called 
"ViaCopy" exists on the main promotion menu. It defaults 
to an "on" position, but can be turned off to signify that the 
data files are being sent to the ALM's reader along with the 
control information. If the files are sent, they must be "read" 
into a temporary holding area while the promotion process 
takes place. Otherwise, they can reside in the user's private 
space until the actual transfer takes place. At this point the 
file is physically copied from the source location to the Entry 
Level. In addition, any subordinate files that belong to this 
file's Automatic File Group are also transferred to their 
destination. 

For a promote, the preferred method is to move the file(s) 
from the source location to the destination location. This 
may result in a simple rename of the file(s) if both physical 
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locations are identical, or it could result in the file(s) being 
physically moved from one server to another. The exception 
to this is if the Retain Source option is specified on the 
promotion screen in Step 22101. This would result in 

5 copying the file(s) from the source to the destination. 

For a BOM Promote, a list of all BOM members is 
returned by the Control Repository in Step 22425. All 
members on this list are moved in the same manner as the 
Anchor file indicated in the main File List. 

10 Similarly, if the current file is the Master of a File Group, 
a list of all subordinates are returned from the Control 
Repository during Step 22425. This list is used to move all 
the subordinates to their target destination. 

For environments incorporating Automated Library 

15 Machines, the ALM must have a means to access and update 
any data within its own library. Whenever possible, all 
ALMs in a given library are provided with read and write 
authority to all physical data repositories. For example, in a 
simple DMS all data within a library would reside in a single 

20 directory, and the ALM would have read and write authority 
to that directory. However, since our embodiment permits 
different PFVLs to reside in separate repositories, this can't 
always be achieved. For instance, one PFVL may reside in 
a Unix or AIX directory, while another PFVL resides on a 

25 VM Minidisk. An ALM running in the Unix/AIX environ- 
ment may not have direct write access to the VM Minidisk. 
The following algorithm is used to handle all types of file 
movements in the DMS, depending on the ALM configu- 
ration and platform environment. 

30 In order to maximize efficiency, the ALM will always try 
to rename or move a file if the environment supports such an 
operation and the source and target PFVL reside in an 
amenable environment such as two Unix/AIX directories 
(same or different) or the same VM Minidisk. In this case, 

35 the ALM attaches to the target repository in a writable 
manner, and performs the move operation. Otherwise, the 
operation is performed by a combination of file copy fol- 
lowed by file deletion. In this case, the algorithm first 
determines if both the source and target repositories are 

40 writable by the ALM. Such is the case for a Conventional 
ALM system or an Actor/Object system running in a Unix/ 
AEX environment. Here, the ALM directly performs the 
copy from the source to the target PFVL. Once the file is 
safely copied, the ALM deletes the source file. In an Actor/ 

45 Object coiifiguration in a VM environment, the Actor must 
send a message to the Object and pass a list of files to be 
copied and deleted. The Object runs a continuous message 
handler which allows multiple Actors to interrupt and ini- 
tiate the copy and deletes. For situations such as a Conven- 

50 tional ALM arrangement running on a VM system, where 
the source and target PFVLs are on different account 
Minidisks, the ALM handling the promotion always has 
write access to the target PFVL. Therefore, it cao directly 
perform the copy operation. The delete is handled by gen- 

55 erating a file deletion request similar to that generated by 
the. File Deletion routine. This job request is transmitted to 
the ALM with write authority for the source repository. 

For promotions involving the movemeot of data across 
different platforms, our embodiment incorporates the con- 

60 cept of a Cross-Platform Transfer. The method differs 
depending on the source and target platforms. Our embodi- 
ment will always try to use the ALM currently executing the 
Promotion algorithm to link to the target platform directly. 
In these cases, the underlying Actor/Object code sets up the 

65 appropriate file transfer protocol and copies the file from the 
source to the destination. It then deletes the file from the 
source repository. The most complex case is when the target 
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environment can't be linked directly by the ALM. Such is current level is the Entry Level. For promotes, it's the 

the case when the ALM is running in a Unix/AlX Source Level. If any files are found with a Destination Level 

environment, but the target PFVL is on a VM Minidisk. higher than the current level, this indicates that further 

Achieving this file transfer involves using dedicated ALMs promotion is necessary, and Step 22435, Promote, is invoked 

running on the source and target platform, which serve as 5 to nandle this. In mis ste P> a promote request is actually 

agents to forward the work requests. The following steps are created listing all files which require further movement. The 

performed: control file also lists their newly acquired level as their 

1 r r\*t% at ha « p^cc ou»r««« Trancfor source level and lists their Destination Level as the target 

1. The ALM prepares a special Cross-FIaUorm Iransier , . , - , . . , . 4 , ... c ° 

request file which contains the source and target level, ^l 1 * 0 ™ ^T 1 d f" thm * ^ A ^ S " P 

the userid of the requester, the type of promote, and a 10 but using the newly created pronnoUoo request as the 

list of all files that need to move This request file and 0°« the current level and Destma- 

the original promote wqucst are copied into a special to ° ^ at t *° ™ m % P™«™* <*>*?l«*- 

punch dLtory whose name is also contained in the „ Me *?* ° f S f"* Relnevu & and Managing Data ,n a 

re uest file Shared Library System 

reques e. The present embodiment incorporates various algorithms 

2. The ALM currently processing the promote, establishes and processes lo permit dala to ^ slored ^ deleled> and 
a socket connection with the VM agent to request a file retrieved from the Data Management System while main- 
transfer to VM. ... taining absolute data integrity. The Data Management Sys- 

3. The VM agent copies all the data from the punch tern (DMS) is comprised of one or more shared public 
directory, and the Cross-Platform Transfer request file 2Q libraries servicing one or more users in a client server 
to its working space. environment. The users may also have private libraries 

4. The request is sent to the appropriate VM Actor, where where work is performed until such time that it is ready to 
it's handled by Steps 29162 and 29163 of the ALM be deposited into a public library for shared access. Our 
algorithm. This algorithm is described in detail in FIG. embodiment has the capability to provide continuous access 
55c. Step 29163 takes care of transferring all the data 25 °£ the shared libraries to large numbers of users. 

as well as deleting the copies from the source reposi- These algorithms and processes are especially suited to 

tory. interacting with the File Promotion Process and Automated 

5. At this point, the code exits the Promotion algorithm, Library Machines (described in the other sections of the 
and the remaining steps in FIG. lSd and 15e are Preferred Embodiment), although they will work without 
performed by the code executed in Step 29163 of the 30 Automated Library Machines and with other File Promotion 
ALM algorithm. Algorithms. 

Note: Our embodiment only supports Cross Platform In order to safely deposit data into the Data Management 

promotions using Actor/Object arrangements. System, our preferred embodiment uses an Installation 

An alternate embodiment permits all the files in the DMS Algorithm described herein. The algonthm is depicted in a 
to reside in the same physical location. Symbolic links 35 library environment using Automated Library Machines 
would serve as place holders and reside in the locations configured in any arrangement, although one skilled in the 
defined by the Data Manager for each PFVL. During a Put, art would appreciate that the algonthm can function in the 
the link would be created while the file is being copied to the absence of ALMs simply by executing in the client's fore- 
master location. During a Promote, the file would be ground environment. 

renamed and the corresponding link would be updated. 40 Tne most frequent initiator of install requests is the 

Depending on the environment, this may provide perfor- Process Manager. The Process Manager executes Automated 

manoe or data maintenance advantages over the preferred Library Processes which create output data that must be 

embodiment. deposited into the DMS. Our embodiment maintains close 

The last step within the File Loop pertains to the Update ties between the output data and the source data used to 
and Overlay Locks established in Steps 22414 and 22417. In 45 create it. If this output data can't be successfully installed 
Step 22433, Rst Lock, the Reset Lock Option is examined. mt0 the DMS, the source data may be prevented from 
If it's on, this signifies the user's desire to leave the file in moving through the DMS or undergoing further processing 
an "unowned" state at the completion of the Put or Promote, until the problem is corrected. Because of the multitude of 
and the program resets any Update Lock that exists for this different types of Automated library Processing, our pro- 
file at the new level. For promotes, an additional step is 50 f erred embodiment contemplates several types of install 
taken to reset the temporary Overlay Lock set in Step 22414 requests combined with a plurality of user options, 
regardless of the Reset Lock Option. The following types of installs are supported 

Control is returned to Step 22412 in FIG. 15c until all files Regular Install Deposits the output into the DMS under 

in the request are exhausted. Upon exit from the loop, full data control. The output file may or may not be 

control is passed to FIG. 15e. Here Step 22427 is again 55 assigned a File Reference number and completely 

invoked to send a message to the user indicating a successful tracked by the Control Repository. Once installed, the 

Put or Promote. The message includes the names of all files file can be processed like any other file in the DMS. The 

processed including Automated File Groups and members of install can be immediate, whereby the install is initiated 

a BOM. and further processing suspends until it completes, or 

Next, the DMS again invokes Step 22421, Process Man- 60 the install can be delayed which means further process- 

ager to run any Post-Processes that exist for any of the files. ing may continue while the Library Manager processes 

Just like with Pre-Processes, the Process Manager handles the install request. 

the entire list of files with a single invocation. High Performance (HP) Install Similar to a Regular 

That last steps in the operation attempt to determine Install, except it deals with groups of component files, 

whether additional promote requests are necessary. In Step 65 This occurs during an Aggregate Install which always 

22434, Prom Req'd, the Destination Level is compared begins with an Anchor file undergoing a Regular 

against the current level for each file in the list. For Puts, the Install, followed by all the related components under- 
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going a High Performance Install. The information determines whether the ALM currently executing the algo- 

Decessary to install the group of files is conveyed rithm is an Actor, and if it's not an Actor it checks to see if 

through a special file transmitted with the Install the request was sent from a different ALM. If so, the 

Request information in the Install Request is written into an Install 

Create DILP Install Used only on the output file of a 5 Recovery file which is used by the ALM Algorithm to 

Create DILP. This install is identical to a Regular Install recover the install in the event of a system crash. Also, in a 

with some additional steps that assign the process result the case where the Install Request is transmitted, the subject 

to the output file once it's safely in the DMS. The data is also transmitted, so it is transferred into the ALM's 

necessary information is passed to the Install algorithm working space. 

through a special file transmitted with the Install W Next, Step 24911 is invoked to perform a Data Access of 

Request * e phys^ repository where the subject data will be 

Regular Store Deposits the output into the Data This may be as ; staple as ensuring the ALM has 

Repository, but the file is not tracked by the Control the proper wnte au honty (such as a l^AIX environment) 

_ r . ' 'r~ £i • . r ,u ^ or it may require linking media such as DASD in a VM 

Repository. These files exist for some other reason than . J 7 1 6 

- • 1 » A fawo 15 environment. 

data management, and don t require any DMS opera- * A m*% . * c t> ^ j n c »u 

, 6 4 Z . i t , . L* Step 24912 tests for Return Code=0 from the previous 

tions (promote, library processing, problem tracking, \ ^ , . t A , t 

\ • . r j •** u • a' * step. A non-zero return code indicates that one or more 

etc.). Th* type of AspostUon can. be unmcdutc or reposiK)lies ^ ^ „ e x ^ of ^ ^ 

Tie Mowing options are supported for the above types P ro P e ' "™ ^J^T^ *% fi SUS 

f " tails- 20 possibly clear the Process Queue. Step 24913 tests to see if 
0 ^ .the Install Request was transmitted by a Remote Execution 

Result: Allows Pseudo Process Results to be set against Machme . If so> me Process Queue Reference Number is 

files being installed. ^ to delete ^ entry from me queue . Furthermore, if an 

Mote: All information is exchanged via a Results File enUy ejdsts and ^ Process phase ^ a p^^ess, then a 

Part Number: Allows Part Numbers to be assigned to files 25 special entry is added to the Process Queue in order to 

being installed. prevent any subsequent Library Processes or movements 

Note: All information is exchanged via a Part Number occurring against the source file used to generate the subject 

File file being installed. This maintains data integrity in the DMS 

Resolve: Allows Library Process Results to be primed for by ensuring that output data always matches input data, and 

files being installed as long as the process structure for 30 input data may not be elevated to the next level unless all 

the installed files is identical to that of the source files. required Library Processes run successfully and the output is 

For example, if a file is copied from a source PFVL to successfully deposited into the repository. Upon completion 

a target PFVL, since the installed file is identical to the of Step 24913, the requestor is notified of the failed instal- 

source file, any Library Process results for the source lation attempt and the program exits, 

file can be automatically propagated to the target file. 35 Returning to Step 24912, if the Return Code equals zero, 

Note: All information is exchanged via a Resolve File then the physical repositories are ready to accept the data 

Now, the program begins by receiving an Install Request and control proceeds to Step 24914. In Step 24914, the Actor 

The Install Request contains the target Version and Level, flag, set in Step 24910 is examined. If the flag indicates that 

the e-mail address of the user initiating the request, the File the current ALM is not an Actor, then the Install Request was 

Name, Type and Package of the subject of the install, the 40 transmitted with a Cyclic Redundancy code which pertains 

Level Reference Number, one or more File Reference Num- to the data being installed. The program generates a new 

bers representing the data which was used to create the CRC Code using the subject data in the working area and 

subject data, a multiplicity of user options, and a flag compares this with the code embedded in the request file. If 

indicating whether a new File Reference number should be they don't match, a transmission error occurred which is a 

acquired for the subject data or whether an existing refer- 45 data integrity violation. This results in a message being 

cnce number should be retained. This information is gener- returned to the requestor, and the program aborting, 

ated by the algorithm responsible for creating new data Assuming the transmission occurred successfully in a 

which needs to be installed in the DMS. A typical example Conventional System, or if the current ALM is an Actor, 

would be our Background Automated Library Processing. then control continues with Step 24916 which sets the Fix 

In a Conventional System, this request may be transmitted 50 Management Flag This flag is passed to the underlying 

from a Remote Execution Machine to a Primary ALM QRSUPGEN routine to tell it whether to propagate the 

whose responsible for installing the data. In this case, the Problem Fix Management data from the source files to the 

Install Request contains additional information regarding subject file. This flag is set to "true" if the Package is in 

the Process Manager's Process Queue. This includes the Single Fix Tracking or Engineering Change Mode and the 

Library Processing Phase (Pre, Post or DILP), the File 55 Library File Type has its Fix Management flag active. 

Reference of the file used to set the Processing Lock and the At this point, control is passed to Step 24918. In the 

Process Queue Reference Number. A Checksum or Cyclic preferred embodiment, Step 24918 is exercised before Step 

Redundancy Code is also included to help detect transmis- 24922, but these are independent tests which can be per- 

sion errors in the data. Id an Actor/Object arrangement, the formed in either order. In Step 24918, the Create DILP 

Actor can execute this algorithm directly, so there's no need 60 option is examined. If the current request is for output 

to transmit the request. In this situation, no Process Queue generated by a Create DILP, then Step 24919 is executed to 

entry is required and no CRC code is needed. However, the Read the Create DILP Info. This information is stored in a 

Install Request file is still created. separate file which accompanies the Install Request and the 

The algorithm begins with Step 24910, which Reads the subject data. The file contains the true name of the output 

Request File into a data structure. In addition any user 65 file, which may differ from the name contained in the Install 

options are examined and for those requiring separate sup- Request. Create DILPs are part of our library process. This 

port files, the file names are assembled. The program also file also contains the Log and Process Reference Numbers of 
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the Library Process which created the file, and the Library 
Process Return Code. Step 24920 is then invoked to Create 
Recovery Information. This consists of generating a Create 
DILP Recovery File which includes all the information in 
the Create DILP file along with the corresponding Control 
Repository command required to store the information in the 
DMS. In the event of a system crash, the ALM Algorithm 
will use this file to exercise all the steps necessary to recover 
and complete the installation. 

Finally, Step 24921 performs a File Copy into the reposi- 
tory. The file is copied here temporarily so it's sure to exist 
in the event of a crash. However, if the subject file is 
overlaying an existing file, the existing file is backed up first. 
This enables the ALM Algorithm to completely and accu- 
rately reproduce the state of the DMS if the subject file is 
unable to be properly installed. A flag is written into the 
recovery file indicating whether an overlaid file has been 
backed up. 

If the current request is not for a Create DILP, then Step 

24922 is employed to test for a High Performance install. 
This option can be requested to install a group of files. Our 
embodiment requires that at least one member of the group 
to act as an Anchor file. This means it must endure all the 
normal checking of a regular install. The remaining files 
benefit from the High Performance install which eliminates 
certain checks that are redundant to those done on the 
Anchor file. The list of files to be installed is maintained in 
a separate file transmitted with the Install Request. Step 

24923 Reads the File List into a data structure that will 
eventually be passed to the Control Repository. 

Step 24924 is then invoked to Access All the Repositories 
necessary to accommodate the entire list of files. Since our 
embodiment permits the list to include files of differing 
PFVLs, and files may be physically segregated down to the 
PFVL granularity, a plurality of repositories may have to be 
acquired. The method of access is identical to that performed 
for the subject file in Step 24911. 

Whether the tests performed in Steps 24918 and 24922 
are true or not, control eventually reaches Step 24928 which 
Updates the Control Repository. This step consists of updat- 
ing all the necessary tables with the information required to 
track the subject file(s). In the case of a Create DILP or 
regular install, the QRSUPGEN routine, is called. In addi- 
tion to the File Name and PFVL information, the algorithm 
also passes the New File Reference flag, the Problem Fix 
Management flag, and any of the Source File Reference 
numbers pertaining to the source data used to create this 
data. In the case of a High Performance install, the same 
information is passed with the exception of the Problem Fix 
Management flag. Instead a list of the entire file group is 
passed. If an error occurs, such as the existence of a lock 
which prevents the install, and this is a Create DILP which 
necessitated the back up of an old subject file in Step 24921, 
then the backed up file is restored. All severe errors during 
this step result in a message being sent to the user, followed 
by the immediate termination of the installation. 

If no severe errors occurred during Step 24928, then 
control proceeds to Step 24930 in FIG. 33c. Here the return 
code of QRSUPGEN is examined for a Bill of Materials 
(BOM) Invalidation Message. Two types of warnings exist. 
One case is when the subject file overlays an existing file 
which happens to be the Anchor of a BOM. In this case, the 
BOM is deleted and the owner of the BOM is notified. The 
other case is when the subject file overlays a file which is the 
member of a BOM. In this case, the BOM becomes invalid 
and the owner of the BOM is again notified. 

Next the program again invokes Step 24918 to test the 
Create DILP option. If this is a Create DILP install, then Step 
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24932 is employed to store the Process Result into the 
Control Repository. This result, along with the Process and 
Log Reference Numbers are contained in the Create DILP 
file. Since a Create DILP requires the Library Process result 

5 to be recorded against a file that doesn't exist when the 
process completes, the Process Manager must forfeit the 
setting of the LP result to the Install algorithm. Once the 
result is set in the Control Repository, Step 24933 checks to 
see if an overlaid backup file exists from Step 24921, and if 

10 so, it Erases the Backup file. It also erases the Create DILP 
recovery file, since all the steps that can be recovered have 
succeeded. 

Control eventually reaches Step 24934 which Deposits 
the File into the data repository. The program checks to see 

15 whether the cut-rent ALM is an Actor. If so, and the 
environment allows the Actor to have direct write authority 
to the repository (such as Unix/AIX), the ALM copies the 
subject file from the Actor's working space to the target 
repository. If it's an environment such as VM, then the Actor 

20 establishes a communication link with the corresponding 
Object ALM, and requests the file copy. If the current ALM 
is not an Actor, then it must have write authority to the 
repository, so it simply copies the file from the working 
space to the physical location. If the current install request 

25 is for a High Performance install, the same steps are run 
against each file in the file list except for the Anchor. The 
Anchor is bypassed since the definition of a High Perfor- 
mance install requires the Anchor to be installed separately 
using a regular install request 

30 Next, Step 24935 is performed to test for the Result 
Option. If this option is passed, then there are Pseudo 
Process results which need to be recorded against the subject 
file. Step 24936 is employed to Read the Results File which 
contains the Pseudo-Process Name, the result, an optional 

35 message, and the name and PFVL information of the file for 
which the result should be recorded against. The code looks 
through the file for a matching file name and PFVL, and if 
one is found, it calls upon Step 24937 to Set the Pseudo. This 
is done via a function in the Process Manager to set the 

40 Pseudo-Process result into the Control Repository. Disclo- 
sure # PO996-0009 contains more information on Pseudo- 
Processes and the Application Program Interface that allows 
other routines to set them. 

Eventually control passes to Step 24938 which tests for 

45 the Resolve Option. This option allows Library Process 
results from a different PFVL to be recorded against iden- 
tical processes for the subject FFVL. If this option is passed, 
Step 24939 Reads the Resolve File which contains the 
Process Name, Process Reference Number, PFVL inform a - 

50 don where the source process resides, the Process Result to 
be recorded, the File Name and PFVL of the subject file and 
an optional Process Message. 

Step 24940 is then employed to Find the Matching 
Process. This is done by querying the Control Repository for 

55 all processes defined for the source PFVL. The code loops 
through the process definitions until it finds one whose 
Process Name and Reference Number match the information 
in the Resolve File. If no match is found, the information in 
the Resolve File is inaccurate, and the program terminates 

60 with a message sent to the user. If a matching process is 
found, the exact location in the process structure is saved. 
Next, the control repository is queried for the process 
structure defined for the subject PFVL. The same location in 
the process structure is examined to ensure the Process 

65 Name is identical to that listed in the Resolve File. If not, 
then the structures are different, and the rule regarding use 
of this option is violated, thus causing the process to abort. 
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If the Process Names match, the Process Reference of the of the file. Fields 25902 thru 25904 are used to denote the 

subject PFVL is used to query the Control Repository and Library Name, Library File Type and Version in which the 

store the Process Result and Message against the file being data permanently resides. If the file is currently in a private 

installed. Step 24941 interacts with the Process Manager to library, the user enters the name of the public library to 

Store the Result into the Control Repository. 5 which the file will be promoted to in the future. Drop down 

Eventually, Step 24942 is invoked to test for the Part menu buttons 25907 can be used to display a list of all the 

Number Option This option is used to store PIN information known public libraries in the DMS. Button 25908 will 

against the subject file. If this option is passed, Step 24943 display a list of the valid Library File Types used in the 

is called to Read the Part Number File which contains the library. Likewise, button 25909 will show all valid Versions 

Part Number, the File Name and PFVL for whom the Part 10 for the given library. If no library name is entered, then 

Number belongs, and the owner of the P/N The program clicking on either button 25908 or 25909 will produce an 

loops through the Part Number File until it finds an entry empty selection list 

whose File Name and PFVL match the subject file. Step Field 25905 represents the Starting Level for the library 

24944 is then employed to interact with our Release Control search engine to conduct the search. This doesn't mean the 

Manager, to Assign the Part Number information into the 15 file must exist at this Level, it's simply where the user 

Control Repository. desires the search to begin. This can be any valid Level 

Note: In the case of a High Performance install, the associated with the Library entered in field 25902, or it can 

subject file referred to in Steps 24935 through 24944 would be the keyword user. This keyword instructs the search' 

actually be all files in the High Performance File List whose engine to first inspect the user's private library for the file, 

names and PFVLs match those listed in the Results, Resolve 20 If it's not found there, then the search engine should traverse 

and Part Number files. the library structure beginning with the Entry Level denoted 

Finally, Step 24913 is executed in the event that a Process by field 25906. Drop down menu button 25910 can be used 

Queue entry requires clean-up. If the install request was to acquire a list of all available Levels for the Library, 

received from an ALM other than the current ALM, then the Version, and Type entered in fields 25902 thru 25904. One 

sending ALM set an entry in the Process Queue. That 25 of the choices is always the keyword user. 

Process Queue Reference number is included in the install The Entry Level field, 25906, serves two purposes. The 

request, and is used to remove the entry from the queue. In first is to provide direction for the library search engine in 

addition, if the Process Phase is a Pre-Process, and any part the event that field 25905 indicates user, but the file is not 

of the algorithm failed to complete successfully, then a found in the user's private library. In this case, the search 

special entry is added to the Process Queue to prevent any 30 engine will begin at the level entered in field 25906 and 

subsequent Library Processes from executing against the traverse through the library structure until the file is located, 

source files. In addition, the source files are prohibited from The second purpose is to determine which level the Update 

moving through the DMS until the install can be success- Lock is to be associated with. Our embodiment permits 

fully retried. multiple users to hold Update locks on the same file, but at 

File Check Out Utility 35 different entry points into the DMS. Button 25911 displays 

Our embodiment permits the user to request ownership of a list of all valid Levels for the given Library, but unlike field 

any file in the DMS and associate that ownership with an 25905, the keyword user is not permitted, 

entry point into the library. This concept of ownership by The algorithm for checking data out of the library begins 

entry point allows a sophisticated environment to exist with Step 25951, SLL=User. Here the Starting Library Level 

where one owner can modify data at one level, promote the 40 entered in field 25905 is checked to see if it's the User Level 

data to a higher level, and a second owner can make further of a private library. If so, the user's private library is 

modifications. The DMS Architecture also permits a user to examined to see if the User File Exists in Step 25952. If so, 

set Update Locks at non-entry Levels, or set locks on ALL the Lock Check subroutine illustrated in is invoked and the 

Levels which prevents another user from modifying or program complete s. The Lock Check routine is discussed in 

moving the file. However, these actions are not part of the 45 greater detail later. 

File Check Out Utility and must be performed through a lock If the file doesn't already exist in the User's private 

setting utility in the Lock Manager. library, then the SLL Library Search is employed. The 

The user is also given the option to physically copy the standard library search engine is used to seek out the most 

file from a public library into their private library. The entire recent copy of the file starting at the User Level. The search 

operation suns in the user's environment without the aid of 50 engine also uses the Entry Library Level entered in field 

an Automated Library Machine. The request will be honored 25906 of to direct the search through the proper entry point, 

or rejected depending on the current state of ownership and If no file is found, the user is asking for an Update lock on 

the relationship of the user to the current owner. The user a non-existent file which is an error condition that tenninates 

initiates the operation with the File Check Out menu. the program. At the conclusion of the search the user is 

The preferred embodiment presents the user screen in a 55 shown the solution of the search. The Lock Check subrou- 

graphical environment where the user engages pull down tine is again used to establish an Update lock. Upon return 

menus, pop-up menus, drop-down lists, radio buttons, push from the Lock Check routine, Step 25954, File Copy, is 

buttons, fill-in fields, and mouse interaction. It should be invoked. The program asks the user for permission to copy 

noted, however, that all functions discussed further in the the file from the Library Level into the User's private library, 

preferred embodiment can be implemented using simple text 60 The file is renamed to the SLL, which is user in this case, and 

screens, or more advanced data entry systems such as touch the program completes. 

screens, voice commands or 3-D graphics. The preferred Returning to Step 25951, if the SLL is not the User level, 

embodiment depicts the method most conducive to the it's assumed to be a valid Level for the Library, Library File 

Motif™, Windows™, and OS/2™ application environ- Type and Version entered on the menu. This Starting Library 

ments. 65 Level is used to initiate the library search engine. Upon 

The screen contains six data entry fields, labeled 25901 completion of the search, the soluuon to the search is shown 

thru 25906. Field 25901 is where the user types in the name to the user. The Lock Check subroutine is invoked, and upon 
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return, Step 25955 is employed to see if the Starting library buttons, fill-in fields, and mouse interaction. It should be 

Level Ffle Exists. If not, Step 25954 is again invoked to copy noted, however, that all functions discussed further in the 

the file to the user's private Library and rename it to the preferred embodiment can be implemented using simple text 

Starting Library Level The user is given the opportunity to screens, or more advanced data entry systems such as touch 

confirm this operation. 5 screens, voice commands or 3-D graphics. The preferred 

If a file already exists with the same Starting library ^ mb ^ e £. dfPicte the method most conducive to the 
Level, the program indicates this to the user, in Step 25956, Motif™, Windows'™, and OS/2™ application environ- 
by showrog the solution of Uie search along ^ the file in ^^ a ^^^^^ McMb9 
the user s library. The user u given itte opportunity to h 2gm thfU ^ Fiek , ^ ^ where ^ user 
replace the private copy of the file with the horary copy If 10 m ^ Namc rf ^ fik ^ ^ ^ Qame 
the user accepts it, the file is copied and renamed using the ^ directl 0f leaye h bkok to generate a selection list which 
Starting Library Level. If the user rejects it, the program the ^ tQ choose multiple mes t0 de i ete . Fie id 
terminates with the end result being an Update Lock set on 2 8212 denotes the Library where the file(s) reside. This 
the existing file in the private library. function is only intended for data tracked in a public library, 

Turning to the Lock Check Subroutine, the algorithm is therefore this field must contain the name of a valid public 

begins with Step 25960 which calls upon the QRSUPGET to library. Drop down menu button 28216 can be used to obtain 

return all the lock and authority information about the file. a list of all the public libraries in the DMS. 

Next, Step 25961, ELL Lock examines these locks to see if" Fields 28213 thru 28215 aire used to enter the Library File 

any are owned by someone other than the user. If so, these Type, Version and Level where the file(s) reside. Button 

other locks are displayed so the user can see who else claims 20 28217 will display a list of the Library File Types used in the 

ownership of the file. If another user has any ownership Library, button 28218 will show all valid Versions and 

locks (at the same or different level), the user is given the button 28219 will display all valid Levels. This information 

opportunity to abort the check out. In addition, the user is is used to initiate a library search for the file specified in field 

also notified whether they have the proper authority to 28211. In the event the file doesn't exist at the specified 

promote this file into the desired Entry Library Level. 25 Level and Version, a dialog box will display the closest file 

If a lock exists for the Entry Library Level, it's checked f°™ d library search. The user is given the oppomnity 

• e* icojo ™ -r iu~ tl-, i t T r e „ llc ^ r to accept or reject the result of the search. If field 28211 is 

in Step 25962 to see if the User Owns It If so the user ^ selection list resulting from the library search 

officially owns the "key* to this "entry door* and the routine ^ be ^ ^ ^ ^ J ^ ^ > ^ ^ 

passes control back to the main algorithm User Surgte, is desired 

invoked. Here, the database is queried to see if the user is a 30 {q ^ cflscs whcfC (hc me processed is under Part 

valid surrogate for the current owner of the lock. If not, then Number or Problem Fix Control, the user can explicitly 

the user is told why the lock can't be set in their favor and specify the Level and/or Version of the previous file which 

the program terminates. If the user is a valid surrogate, then should be used to reassociate the Part Number and/or 

Step 25964, Reset/Notify is employed. In this step, the user reactivate the Fix Management data. The Level and version 

is told who currently owns the lock and is given the 35 are entered in fields 28220 and 28221 respectively. These 

opportunity to take ownership. If the user accepts it, the fields are optional, and if left blank will cause the Fore- 

DMS sends a notification to the previous owner indicating ground process to interact with the user to obtain the 

that the user has now taken ownership of this entry point. information. Drop down menu buttons 28222 and 28223 can 

The routine returns control to the check out algorithm. be used to show a list of valid Levels and Versions for the 

Returning to Step 25961, if no Update lock corresponding 40 corresponding Library, 

to the Entry Library Level exists, then an Entry library The only option for this operation is the Model option 

Level Lock is Set in Step 25965 for the user. This is done via which the user can specify via push button 28224. This is the 

interaction with our various Loch. Manager functions. means by which the user acknowledges that deletion of the 

At this point the program returns control to the main file will cause either Bill of Materials deletion or invalida- 

algorithm. 45 tion. 

File Deletion Utility Returning to the overall flowchart, information entered in 

Since data integrity can be easily compromised by uncon- Step 28101 is now passed to Step 28102, Foreground 
trolled file deletion, our embodiment provides a robust Processing. The detailed algorithm for generating file dele- 
utility for deleting data in a safe and orderly manner. It also tion requests begins with Step 28311, Parse Opts. Here all 
ensures that the control information such as Problem Fix 50 the options are examined to ensure they are recognized and 
Numbers and Part Numbers are correctly handled. The the values are acceptable. If Previous File Info is passed as 
preferred embodiment depicts the overall flow of the delete an option, the values are checked to ensure they exist for the 
or data removal. given library. 

The flow begins with Step 28101, Entry Screen, where the In Step 28312, a File Loop is initiated in the event the user 

user is presented with the File Deletion Screen. This screen, 55 selected multiple files from the user screen in Step 28101. In 

permits the user to enter information about the filers) they this case each file must be subjected to the same checks and 

wish to process. In Step 28102, Foreground, the information tests since each file possesses individual characteristics, 

gathered in Step 28101 is processed and additional infor- The next series of steps pertain to handling Bill of 

mation may be requested . Some basic checks are performed Materials (BOMs), if they exist Beginning with Step 28313, 

before passing control to Step 28103. In Step 28103, 60 Model Opt, the program tests the Model Option flag. If this 

Background, our preferred embodiment processes the flag is true, it indicates the user accepts the possibility of 

request on an Automated Library Machine since these are BOM Deletion or Invalidation and does not wish to be 

the only users with the proper permission to edit or delete warned in advance of the consequences. One example is the 

data within the DMS. act of deleting a file which is an anchor to a BOM. If the user 

The preferred embodiment presents the user screen in a 65 knows this in advance, they can pass this option to avoid 

graphical environment where the user engages pull down unnecessary checks. In this case control proceeds to Step 

menus, pop-up menus, drop-down lists, radio buttons, push 28317. 
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However, if this option is absent, Step 28314 is invoked PN/FM information was trapped in Step 28322, control 

to check for BOM Deletion. Here, the Control Repository is proceeds to Step 28326. In this step, the Level of the file 

queried to see if the current file is a BOM. If so, Step 28315, being deleted is checked to sec if it's a Release Level This 

Warn User is employed to notify the user of the impending includes active or frozen Release or Sideways Levels. If the 

BOM deletion. The user is given an opportunity to abort the 5 Level is any of the aforementioned types, Step 28315 is 

process. The next step, 28316, queries the repository for any invoked to warn the user and provide an opportunity to 

BOM Invalidation. This tests for the situation where the abort. 

current file belongs to some other BOM, so its removal will Control eventually proceeds to Step 28328, PN/FM 

result in a BOM becoming invalid. Our Aggregate Manager Re-assoc. In this step, the algorithm uses the information 

is used to quickly locate any BOMs in the DMS which lQ trapped in Step 28322 to interact with the Control Reposi- 

contain this file. tory. It eliminates all Part Number information associated 

Once again, if an invalidation will occur, Step 28315 is with the file about to be deleted, and reincarnates all Part 

employed to notify the user and give them the chance to Number information pertaining to the file found in the 

abort the deletion. previous step. In addition, the superseded Problem Fix 

Regardless of the setting of the Model Option flag, control numbers attached to the file are converted to an active state, 

eventually proceeds to Step 28317, File Check. In this step, 15 ^ appropriate Number and Fix Management tables 

the algorithm queries the database to ensure the file exists in the repository are updated to reflect a state whereby 

the Control Repository and the repository agrees on the me evious file assumes ^ role 0 f the file being deleted. 

Uvel and Vfersion. If the Uvel and ^ Version returned by the { retums ^ ^ ^ ^ 

Control Repository are not identical to that indicated by the ^ beeQ ^ 

k ^ P .k X ' ^ OCCUIS USer 20 Steps 28313 thru 28325, control proceeds to Step 28329, 

and aborts, the program. Utiles. Here the Filenames, Library, Level, Version, 

The algorithm proceeds to Step 28318 where the Part _ „ „ , 0 r; 3 , ... 

vt t_ j r- w » r-i „ l, • a j c Library File Type, and File Reference numbers are written 

Number and Fix Management Flags are obtained from the \ J £ ! _ . ... . n , ^ . , , 

Control Repository and examined for the Library File Type f° a ^ a f y . Dckt f. L f . ^ wJl be transited to the 

being processed. If the LFT is under Part Number Contiol 25 *f.chme in the next step. 

Single Fix Tracking or Engineering Change Mode, control □ step 28330. the program gathers an '"teaU 

a . o* uSifl t c7 loftn nw)rn/ -t of the necessary data to the Design Control System. In our 

proceeds to Step 28319. In Step 28319, PN/FM Info, all Part J A 

i_ j r? * m f • r u* • j c preferred embodiment, the destination would be an Auto- 
Number and Fix Management informaUon is obtained for K 4 * _ , . . . . ' ... . . • tUa . fnr 
. c, . - j T jjv it u i mated Library Machine which would "receive the infor- 

the file being processed. In addiuon, all obsolete files, of the a ♦ d ^ -n, frtl , n „' 

« * i_ • l. i i « . « . . • j . .« „ maUon from the user via an AutoReader The following 

same name, and at higher levels, which are attached to the 30 * . . , , . . . . . . & 

same part number andXr attached to the same EC Number formation need to be ttansmitted in the delete request: 

are also returned. ™ e ^ of re <l uest: Delete 

At this point the algorithm determines which dormant file, The list of files being promoted. The following mforma- 

if any, will be used to reassociate the Part Number and/or tion must exist for each me 111 hs{: 

reactivate the Fix Management information. First, the Pre- 35 Th e Filename 

vious File Info fields 28220 and 28221 are examined in Step T°e library File Type 

28320. If the user specifies a particular level or version, they ^h c Package 

are expecting the corresponding file to be used to reassociate Tae Version 

the PN and/or revalidate the problem fix numbers. In this Tne Level 

case, the program employs Step 28321, Locate Previous 40 Any user selected options that pertain to the background 

File, to sift through the data returned in Step 28319 in search operation. 

of the expected file. If the file is not in the list, it's an error The user's electronic id or e-mail address, 
condition and the program terminates. Assuming the file This file is transmitted to the ALM for use in the Back- 
exists, the program proceeds to Step 28322, Trap PN/FM ground Processing step. 

Info. In this step, the algorithm sets a flag and remembers all 45 Returning to the overall process, the foreground informa- 

the information necessary to disassociate the old Part Num- tion in Step 28102 is transmitted to an Automated Library 

ber and Fix Management data from the file about to be Machine for background processing. The detailed algorithm 

deleted. It also captures the information about the file for Step 28103, Background, begins when the algorithm 

selected for re-association. Although the information is enters a File Loop, in Step 28411, where the list of files 

captured, the actual updating of the Control Repository is 50 transmitted from the Foreground are processed into a data 

done in a later step. structure. Each step in this algorithm must be performed 

If the Previous File Info fields are empty, the programs against every file in the list, 

checks to see if the list returned in Step 28319 only contains Step 28413 obtains the Lock Information for the file from 

a single entry. If so, Step 28315 is invoked to warn the user the Control Repository. This includes information about 

that the file in the list will be the one used for PN/FM 55 every possible lock the file possesses at any Level within this 

reassociation. It also provides an opportunity to abort the Version. In the subsequent steps, the list of locks are 

process. If the user accepts this, Step 28322 is employed to exarnined and different actions are taken depending on the 

capture the information. types of locks in existence. 

The last possible case for PN/FM re-association, Step Step 28414 checks to see if any Processing Locks exist on 

28324, involves a list with >1 File being returned in Step 60 the file at the specified Level. This would indicate a Library 

28319. If this is the situation and no Previous File Informa- Process is currently dependant on the existence of the file, so 

tion is provided, the program uses Step 28325 to present the Step 28415 is invoked to Recirculate the delete request. In 

user with a Selection List The user may select only one entry our preferred embodiment this entails re-writing the delete 

or abort the operation. Assuming one is selected, Step 28322 request file with the names of all the unprocessed files, and 

is invoked to capture the information. 65 sending it back to the main queue of the DMS. In a simple 

If the Part Number and Fix Management Flags in Step system without Automated Library Machines, the necessary 

28318 are off, or no files were returned in Step 28319, or any action would be to introduce the request back into the DMS 
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queue or inform the user to try again at a later time. At this preferred embodiment, the method of removal depends on 

point the processing is complete. the ALM configuration employed. In a Conventional System 

If no processing locks exist, Step 28416 checks for Move or any arrangement running on a Unix/AIX platform, the 

or Overlay Locks at the Level where the file exists. In either ALM can delete the file without assistance. However, in an 

type exists, Step 28420 Sends an Error Message to the user 5 Actor/Object configuration running on a system such as VM, 

indicating that the file can't be erased. The program termi- or a complex system involving multiple computer platforms, 

nates after the notification is sent the ALM may need to request the Object to perform the file 

If no Move or Overlay Locks exist the program proceeds removal, 

to where Step 28417 examines any Update Locks that exist. Control returns to the top of the File Loop in Step 28411 

In this step all Update locks are examined regardless of the 10 until all files in the request are processed successfully. The 

Level. In Step 28418 a determination is made as to whether operation then exits with a success message sent to the user, 

the User Owns All the Update Locks If this is true, then the Automated Library Machines (ALMs) 

user is the official owner of the file according to the rules of Our embodiment contemplates the use of Automated 

the DMS. In this case, control can proceed to Step 28421. Library Machines (ALM) to process the work requests on 

If there are some Update Locks which the user doesn't is behalf of the users. Although this embodiment is ideally 

own, or no Update Locks exist at all, then the program suited for the various process and methods described in the 

checks to see if the user is the Package Manager or Alternate other sections of the Preferred Embodiment, ALMs are not 

in Step 28419. As long as the user is the Data Manager or confined to running only those processes. ALMs may exist 

a valid alternate, the program is allowed to proceed to Step in Data Management Systems running processes and algo- 

28421. If the user is not a Data Manager, Step 28420 is 20 rithms outside of those mentioned in this disclosure, 

invoked to send an Error Message indicating the situation, Our embodiment employs an Automated Library Machine 

and the program terminates. (ALM) to service data management requests on behalf of the 

Assuming that the user meets one of the authority criteria, users. This enables the user to initiate a library job such as 

control proceeds to Step 28421 where the File is Checked to promotion request, Designer Initiated Library Process, or 

ensure the Control Repository agrees that it exists at the 25 delete request without requiring significant client resources, 

specified Level and Version, and ensure the file doesn't The ALM provides continuous service by utilizing the 

reside in a frozen Release Level. concept of a reader to queue and prioritize users' requests. 

Next, the algorithm checks the Fix Management Flag in Performance of the Control Repository may also benefit 

Step 28422. This consists of querying the Control Reposi- since the most of the communication is with a relatively 

tory to see if the FM flag exists for that Library File Type. 30 small number of ALMs compared to the larger number of 

If so, Step 28423 is invoked to Delete the Fix Management individual users. 

Information pertaining to the file. This is done via our Fix The preferred embodiment uses ALMs to execute all the 

Management routines. Background algorithms included in the embodiment. One 

Step 28424 performs a similar function with the Part skilled in the art would appreciate that an alternate embodi- 

Number Flag The repository is queried to see if the PN flag 35 men! doesn't require ALMs by eliminating all the transmittal 

exists for the LFT being processed. If so, Step 28425 is steps in the various Foreground algorithms, and simply 

implemented to Delete the Part Number Information per- running the Background algorithms on the client machines, 

taming to the file. This is done via our Part Number routines. As eluded to above, this may require substantial client 

At this point control is passed to Step 28426 to Delete the resource and may compromise performance of the Control 

Lock Information pertaining to the file. This is done via our 40 Repository. 

Lock Management routines. If the user is a Data Manager, For large Data Management Systems, our embodiment 

it is possible for the file to be in a completely unowned state. permits the creation of multiple ALMs to service a single 

In this case, the DMS will not abort, but will continue with library. This enables large user groups to redeem faster 

the next step. results through the use of parallel processing. The Data 

In Step 28427, the QRFILDEL routine, described in FIG. 45 Manager has the option of arranging the pool of ALMs in 
11, is employed to Delete the File from the Control Reposi- one of three configurations depending on the expected type 
tory. This entails updating the necessary files tables to and volume of data management requests. The basic con- 
eradicate any associated entries. figuration is known as a Conventional System where a single 

Steps 28428 thru 28430 are designed to handle any Bill of ALM accepts all work requests and handles all services for 

Materials associated with the file. In Step 28428, the DMS 50 the Library Manager, including any Automated Library 

checks to see if the file itself is the anchor file of a BOM. If Processing. The second configuration is Remote Execution 

so, BOM Deletion will occur for all BOMs associated with Machines which is an extension of the Conventional Sys- 

the file. Step 28430 is invoked to Notify the owners of all the tem. Here, a single ALM receives all work requests from the 

BOMs about the elimination. BOM deletion is Performed user, and processes all promotion, installation, movement, 

via our Aggregation Management routines. 55 and removal of data. However, additional ALMs may exist 

In Step 28429 the DMS checks to see if any BOMs are to perform Automated Library Processing. The ALMs inter- 
Invalidated by the removal of the file. If so, Step 28430 is act with the Library Manager, Communication Manager and 
again invoked to notify all owners of any affected BOMs. Promotion Algorithm to dispatch any desired library pro- 
BOM invalidation is performed via our Aggregation Man- cessing to a Remote Execution Machine, which executes the 
agement routines. 60 task and returns the results to the master ALM. The most 

The last step in the File Loop is Step 28431 which will powerful configuration is known Actor/Objects and this 

Erase the File. This includes obtaining the physical location arrangement employs a pool of ALMs which serve as 

of the file from the Control Repository and performing the general purpose machines. They can perform any desired 

deletion. Depending on the environment, the Automated Library Management function, including Automated Library 

Library Machine may have the proper permission to perform 65 Processing. They can even interface with Remote Execution 

a direct removal, or it may have to transmit a request to an Machines to provide an environment with both general 

agent which is capable of performing the removal. In our purpose machines and dedicated service machines. Each 
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Actor can be programmed by the Data Manager to define the 
type of work requests it can process. This arrangement even 
includes a special Dispatcher ALM whose sole purpose is to 
dispatch user work requests to the next available Actor 
machine. 

The means by which data is physically moved between, 
added to, or deleted from, the repositories depends on the 
chosen configuration. In a Conventional System, the primary 
ALM is the only ALM with the proper authority to manage 
files on any repository within its own library. Remote 
Execution Machines may only receive work requests and 
return data and results to the Primary ALM. Our embodi- 
ment does not permit Conventional Systems to process file 
transfers across multiple platforms. 

In this system, all actions are initiated by job requests. 
These may be include: 

Class A: Requests to promote data from abuser's private 
library inio the public library or invoke Designer Ini- 
tiated Library Processes. 

Class B: Requests to promote data through the public 
library. 

Class C: Requests for Automated Library Processing on a 
Remote Execution Machine or responses from Remote 
Execution Machines to indicate completed Library 
Processes. 

Class D: Requests to install new data generated by 
Library Processes on Remote Execution machines, 
delete files from the DMS, or perform Data Manage- 
ment functions. 

The classes represent priorities with Class D being the 
highest and Class A being the lowest. Every ALM in the 
library (Primary ALM and all Remote Execution Machines) 
runs the ALM algorithm as an AutoReader task. AutoReader 
automatically invokes the algorithm whenever a file is 
received in the reader. 

In an Actor/Object system, either the Actors have the 
ability to directly manipulate files in the repositories (such as 
Unix/AIX), or they must rely on a dedicated ALM known as 
an Object to handle all file management tasks. The Object 
has the proper authority for all repositories in the library. The 
Actors run the ALM algorithm as an AutoReader task, just 
like the primary ALM in a conventional system. However, 
many of the Class C and D jobs related to file management 
are replaced by the Actor performing its own file manipu- 
lations (if the environment allows it), or by communication 
with the Object (such as a VM Actor/Object system). 

In systems requiring an Object, communication between 
the Actor and Object is accomplished by an asynchronous 
messaging system where the Actor initiates a request to the 
Object and waits for a response message from the Object. 
The message consists of a command line which includes the: 

Function to be Performed 

Source File Name 

Source File Type 

Target File Name 

Target File Type 

Source Repository 

Target Repository 

The repository fields include enough information to 
physically locate the file regardless of the platform or 
environment. The Object, in turn, runs a continuous routine 
implemented as an AutoReader interrupt hook. Whenever it 
receives a message, the routine "wakes up" and checks to 
ensure the message is from a valid Actor, and contains one 
of the supported functions. It then executes the appropriate 
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function and sends a completion message to the Actor. If 
either the Actor or Object fails to transmit or respond to a 
message successfully, a mechanism will resend the message 
until the handshaking is complete. 

Regardless of the environment, all Actor/Object systems 
support the following functions: 

Rename Move or Rename the file from the source to the 
target location. This is only used on environments 
which support it such as Unix/AIX, or VM when the 
source and target are the same minidisk. 
Copy Copy the file from the source to the target location. 
This is used to install an output file from an Actor into 
the repository, or as the first part of promotions involv- 
ing a Cross-Platform file movement, Cross-Account or 
Cross-Minidisk file movement on VM. 
Delete Delete the file from the source location. This is 
used for File Delete requests or as the second part of 
promotions involving a Cross-Platform file movement, 
Cross-Account or Cross-Minidisk file movement on 
VM. 

Batch Used for multiple files which must be manipulated 
as part of the same task. A batch file is generated listing 
each file along with it's corresponding command line. 
The commands must be one of the three supported 
commands (Rename, Copy or Delete). The ALM loops 
through each line of the batch file and Processes each 
file successively. 
Note: ALMs only deal with file manipulation requests. In 
the preferred embodiment, it's up to the DMS algorithm 
30 overseeing the file movement (such as the Promotion or File 
Installation algorithm) to determine which type of library 
arrangement exists and whether job requests should be 
created and transmitted to a Conventional ALM or Actor/ 
Object commands should be generated and executed. 
35 Therefore, the underlying code for all these algorithms must 
query the DMS for the type of library arrangement. If it's 
Actor/Object, the code must also determine whether the 
environment utilizes an Actor/Object messaging scheme, or 
whether the Actor can execute the Rename, Copy and Delete 
40 functions directly. 

Automated Library Machines are based on the concept of 
an Automated Reader where the Reader is a temporary 
storage area which accepts library requests. A Reader may 
simply be a directory where data is copied into, or it may be 
45 part of the environment such as the VM system. A simplistic 
implementation of an Automated Reader would incorporate 
a continuous loop with a timer to view the files in the Reader 
at specified intervals, and upon finding one, initiating the 
ALM algorithm. However, our preferred embodiment 
50 implements an Automated Reader by using an AutoReader 
service machine. This software machine is capable of per- 
forming many tasks outside the arena of Data Management, 
as well as providing the Automates Reader function. 
Once a file is detected in the Reader, the ALM algorithm 
55 is invoked. It begins with Step 29120 where a registration 
check is performed. All ALMs must be registered with the 
Control Repository, and when registration is complete a flag 
is set. In Step 29120, Reg. Flag, this flag is tested to ensure 
it's set. If not, Step 29121 is invoked to Register the ALM. 
60 The ALM is first checked to ensure it's an authorized user 
of the Control Repository, and if so, it updates the repository 
with certain environmental information such as user id, 
system address, etc. 

Upon completion of the registration, Step 29122 is 
65 executed to test for a Startup command. This is passed into 
the ALM algorithm as an AutoReader parameter whenever 
the machine is re-started. This could be the result of a system 
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crash or a manually initiated command. In the case of an multiple files contain the same priority, they are sorted by 

ALM Startup, various tests are made to attempt to recover time from oldest to most recent. This yields the oldest, 

any interrupted or incomplete tasks. The first test, done in highest priority file. The program then determines if the type 

Step 29125, is for a Process Crash. This is done by looking is a library request. If so, it will be processed, otherwise, the 

for the existence of a Bucket in the ALM's work space. Our 5 sorted list is searched until the oldest, highest priority library 

Process Manager writes a Bucket file each time it begins request is found. This ensures that the library requests are 

running an Automated Library Process. If the process com- done in the proper order, but still permits non-library work 

pletes normally, the Bucket is erased. The existence of a to be intermixed. 

Bucket signifies a Mid-Process crash, which results in Step Next, Step 29124 is invoked to Resolve the Sender of the 

29126 being executed to Send a Message to the user who 10 library request. This entails reading the sender's id and 

requested the Library Process. This information is contained electronic address from the header portion of the work 

in the header of the Bucket file. request At this point control proceeds to a Receive the File. 

Control proceeds to Step 29128 to test for a Create DILP Receiving the file refers to moving the file from the reader 

Recovery file. This file is created during the installation of to the ALM's workspace so downstream programs can 

the output of a special Automated Library Process known as 15 access it. These downstream programs may be the Promo- 

a Create DILP. In the event of an ALM interruption, this file tion algorithm or an Automated Library Process, but our 

contains all the information necessary to retry the file embodiment ensures all ALM 's use identical work spaces, 

installation. Next, Step 29129 checks for the File Existence which are environment specific, so any downstream 'process 

of the Create DILP output. Assuming it's present in the can easily find the data. For example, in an aix/unix 

ALM's work space, Step 29130 in invoked to Automatically 20 environment, a nomenclated subdirectory is used as the 

Retry the installation of all Create DILP output The instal- ALM's work space, whereas temporary DASD is used in a 

lation entails calling the QRSUPGEN function to update the VM system. 

necessary files tables as well as calling QRRESADD to add Steps 29146 through 29163 are used to direct the library 

the Library Process result. request to the proper algorithm. It can best be handled with 

The third test is for a regular Install Crash in Step 29132. 25 a case or select statement, and the don't imply any order for 

This is accomplished by testing for the existence of an Install these steps. Step 29146 tests for a Report Request. Our 

Recovery file. Like the Create DILP Recovery file, this file embodiment permits the user to send requests for various 

is written as part of the file installation algorithm to aid in nightly reports. If Step 29146 tests positive, then Step 

automatic recovery. If it exists, the recovery action is deter- 29147, Rpt is invoked to add the request to the nightly report 

mined by the existence of the Process Phase parameter in the 30 queue file. At a pre-determined time, a service machine 

Install Recovery File. Step 29134 tests for the Process wakes up and processes all the requests in the queue. 

Phase. If it is absent, the installation was not initiated by an Step 29148 tests for a Promote Request. These can be 

Automated Library Process, therefore Step 29136 simply requests to transfer data into a public library from a private 

Recirculates the Install Request. If the phase does exist and library, or move data through a public library. The data may 

the originator of the request is an ALM other than the current 35 be an individual file, a group of files, or an aggregate 

machine, then Step 29138 is executed to test if the Phase- grouping. Regardless of the type of promote, control is 

Pre Process. If so, then Step 29140 will be invoked to call > passed to the Promotion algorithm in Step 29149. This 

the QRPRQADD function to add a special entry to the algorithm is detailed in FIGS. 14 and 15. 

Library Process Queue. This prohibits the file undergoing Step 29150 tests for a Delete Request. These are requests 

Pre-Processuig from moving through the DMS, or executing 40 to delete data from a shared library, and they can be initiated 

any further Library Processes, until the installation can be by the owner of the data or the Data Manager. Delete 

performed successfully. Regardless of the phase, Step requests are handled by the Delete algorithm in Step 29151. 

29142, QRPRQDEL, will eventually be called to delete the The case structure continues with Step 29152 which tests 

entry from the Dbrary Process Queue that was created by for an Install Request. This type of request originates from 

the Install Algorithm to prevent any file creation or move- 45 an ALM acting as a Remote Execution Machine in a 

ment while the installed file is in transit. Conventional Library System. Since the Remote Execution 

Once the appropriate recovery action is completed, or if Machine can only execute Library Processes, but not 

none of the three types of recoverable scenarios are satisfied, manipulate data, it must send a request to the Primary ALM 

control exits the algorithm and returns to the AutoReader to store the data into the repository. In this case, control is 

machine. 50 passed to the Install algorithm in Step 29155. 

Returning to Step 29122. if the current request is not a Step 29154 tests for a Store Request This is almost 

Startup then control proceeds to Step 29123 to Order the identical to the Install Request in Step 29152, except that the 

Reader. This step incorporates a combined algorithm to data is not tracked in the Control Repository. It's simply 

provide first-come-first-serve processing for non-Data Man- deposited into the data repository without any affiliation to 

agement requests, while ensuring Data Management jobs are 55 the library structure. These requests originate under the same 

handled in order of priority. First the file is examined to see circumstances as Install Requests, but they are handled by 

if it's possesses a higher priority than a library request. The the Store algorithm in Step 29155. 

type of request is also checked to see if it's a supported The Store Algorithm in Step 29155 simply consists of 
library request. All library requests contain a LIB keyword reading the file information out of the request file and 
in the job type. If none of these conditions are satisfied, the 60 determining exactly which repository the file should be 
program immediately returns control to the AutoReader stored on. This information is contained within the job 
algorithm to process the non-Data Management request. request. Next, the code receives the file from the reader and 
Otherwise, this is assumed to be a library work request. In copies it into the appropriate repository. Since the file is not 
order to maintain data integrity, all library requests are tracked by the DMS, no queries are made to the Control 
processed in order of highest to lowest priority. Step 29123 65 Repository. Furthermore, the nomenclature on the file con- 
accomplishes this by sorting all reader files, which possess sists only of a Filename, Library File Type and version, 
one of the four job classes, in descending priority order. If There is no Package, Level, or File Reference Number. 
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la Step 29156, the program checks for one of the many 
types of requests associated with Automated Library Pro- 
cesses. Due to the many different library arrangements 
supported by our embodiment, any given ALM may be 
playing the role of a Conventional ALM, Remote Execution 
ALM, or an Actor. This means that any ALM must be 
capable of receiving a job request to initiate an Automated 
library Pre -Process, Post-Process, or a Designer Initiated 
Library Process (DILP). Additionally, it may receive 
responses from completed Pre, Post or DILPs. All requests 
related to Library Processing are handled by our Automated 
Library Processing algorithm in Step 29157. 

Step 29158 is designed to handle requests which Create a 
Structure File. Our preferred embodiment uses Structure 
Files to supplement the Structure Tables in the Control 
Repository. These files contain a formatted list of all the 
Levels and Versions installed for this Package, their 
repositories, and the information linking the Lever and 
Version tree. This permits many of the Data Management 
functions to reference this file instead of querying the 
repository, thereby increasing availability and possibly 
improving performance. In order to assure that these files are 
kept in sync with the Control Repository, any changes made 
by the Data Manager to the library structure result in a 
Create Structure File Request being sent to the library's 
main ALM. Upon receiving it, Step 29159 is invoked to 
Update the Structure File using the latest information in the 
DMS. This step extracts the structure information from the 
Control Repository and writes it into the Structure File with 
the proper format. 

The case structure continues with Step 29160 which tests 
for an Authority Request Data Managers may elect to use 
Authority profiles to generate a master list of authorized 
users for their Package. Every time this list is generated, it's 
sent to the master ALM for the Package, where upon 
receiving it, Step 29161 is invoked to Replace the Autho- 
rized Users List. This simply consists of copying the newly 
received file over the existing user list. Detailed information 
regarding Authority Profiles can be found in our Authority 
Manager. 

Step 29162 tests for a Cross Platform data transfer such as 
a file being promoted from a Unix/AIX platform to a VM 
platform. Step 22432 of our Promotion algorithm, describes 
how files are moved from the source repository to the 
destination. In many cases the ALM running the algorithm 
has the proper access to perform the necessary file transfer 
functions without any assistance. However, cases such as 
this one, don't permit the proper access to the ALM on the 
source platform. Therefore, the source ALM suspends run- 
ning the Promotion algorithm and uses a special ELM, 
running on the target platform, as a communication agent to 
forward a Cross-Platform job request to any ALM on the 
target platform capable of writing to the target repository. 
This ALM on the target platform receives the Cross- 
Platform Data Transfer job request which requires the spe- 
cial algorithm in Step 29163 to be invoked. 

Step 29163 runs the Cross Platform Algorithm, which 
begins by reading the header line from the Cross-Platform 
job request file. Next a loop is established to process each 
file listed in the request. For each file the source repository 
is linked in a read mode, and the destination repository is 
linked in a writable mode. The appropriate file transfer 
• protocol is established and the file is copied to the target 
repository. The copy of the file residing in the source 
repository is then deleted. 

At this point the file movement is completed, so control 
returns to the top of the file loop until all files are moved to 
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their target locations. The code then executes the same steps 
in the Promotion Algorithm that would 've taken place if the 
source ALM performed the file movement. These consist of 
Step 22433 in FIG. 15d and all the steps in FIG. 15*. 
5 If the request keyword doesn't match any of the tests, then 
control is returned to the AutoReader and a message is sent 
to the sender indicating a nonsupported library request. It 
should also be noted that this structure easily permits 
additional types of library requests to be added. For 
example, other environments may require a type of library 
processing not discussed in the preferred embodiment. By 
simply assigning a keyword to that type of request, any 
algorithm or program can be exercised upon receipt of the 
work request. 

On the other hand, if any of the supported algorithms are 

15 executed, they will eventually return control to Step 29170 
to test for a Processing Lock Some of the algorithms such as 
the Promotion and library Processing algorithms may not 
be able to process the current request if it involves data 
currently locked in the DMS. In this case, the algorithms 

20 return a unique return code, which Step 29170 detects. If it 
tests positively, then Step 29171 is invoked to Recirculate 
the request. This entails placing the request back into the 
Reader with the same priority, but a current time stamp. If 
there are no other work requests in the Reader, then this 

25 request will continuously loop through the Reader until the 
Processing Lock relieved and the appropriate algorithm can 
service the request. 

In a DMS utilizing ALMs, all Foreground algorithms 
transmit job requests to the ALMs which execute the Back- 

30 ground algorithms. In order to assist these Foreground 
algorithms in locating the proper ALM to send the request 
to, our embodiment provides the following means. The 
preferred embodiment contemplates the use of a Master 
Library Directory which retains information about every 

35 library in the DMS. The listing is sorted by Package ID, and 
each record indicates whether the libraries for that Package 
are running in Conventional mode or Actor/Object mode. 
Additionally, the record indicates the primary repository for 
that library. This repository holds any data with library- 

40 specific data such as Library Logs, AutoReader control files, 
Actor lists, etc. User data may or may not be located in this 
repository. 

The Master Library Directory may be maintained within 
the Control Repository or as a separate flat file kept in a 

45 commonly accessible location. Since any authorized user of 
the DMS may invoke a Foreground algorithm, all users' 
client environments must have access to this infonnation. 
Regardless of its location, the Foreground algorithms always 
follow this procedure for transmitting job requests. First, the 

50 Package is checked to see if it's running a Conventional or 
Actor/Object system. If it's Conventional, then the primary 
repository is the Primary ALM where all job requests should 
be transmitted. Using the four level Class system explained 
above, the Foreground algorithm directs the job request to 

55 the Primary ALM's reader queue. Eventually, the Auto- 
Reader accepts the job request and initiates an ALM to 
process it. If the Foreground algorithm detects an Actor/ 
Object system, then it must locate the Actor List. This is a 
listing of all the Actors servicing a given library. For each 

60 Actor in the list, information exists denoting the type of 
work requests it's allowed to receive. The Actor List is 
established by the Data Manager using our Data Manage- 
ment Configuration Utilities. A utility exists which permits 
the Data Manager to easily define a multiplicity of Actors 

65 with their corresponding qualifications. This information is 
stored in the Control Repository and may be duplicated in a 
text file which is stored in the primary repository. 
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Once the information in the Actor List is acquired, the Here we will discuss how our preferred Design Control 

Foreground Algorithm looks for a special Actor called a Repository and System Methods can be used with various 

Dispatcher. In systems without dispatchers, the algorithm changes which need to be adopted for existing software in 

simply scans the Actor List until it finds an Actor capable of order to make use of that software in our new environment, 

accepting the type of work request being transmitted. If 5 In this area we will discuss the AFS environment. In order 

more than one work request is being generated, and more to be used commercially in the future, we believe that the 

than one Actor is capable of accepting that type of work, the current software, now insufficient for our complex needs, 

requests are distributed evenly between the Actors in a needs to be changed. Our PFVL structure and principles are 

simple round robin scheme. However, our embodiment adopted. 

incorporates the use of a Dispatcher to maximize efficiency 10 As one reads this, one will appreciate that we now have 

by receiving all work requests from all users into a single a data management system for file and database manage- 

"Bank Teller" queue. The Dispatcher is a special purpose ment which has a design control system suitable for use in 

ALM whose sole job is to accept work requests from users connection with the design of integrated circuits and other 

client machines, and dole them out to the next available elements of manufacture having many parts which need to 

Actor capable of servicing that particular request The 15 be developed in a concurrent engineering environment with 

Dispatcher ALM runs a special Dispatching algorithm which inputs provides by users and or systems which may be 

is described below. Once the work request reaches the Actor, located anywhere in the world . Using our PFVL structure 

it's handled in the same manner as a Conventional System and process principles as the foundation for the architecture 

whereby the request is received and processed by the ALM we provide a set of control information for coordinating 

algorithm. 2 o movemenl °* me design information through development 

Note: Work requests generated in the users' environment and to release while providing dynamic tracking of the status 

are never sent directly to Remote Execution Machines. The of elements of the bills of materials in an integrated and 

use of a Remote Execution Machine is specified for Auto- coordinated activity control system utilizing a control 

mated Library Processes by the Data Manager. When a user repository which can be implemented in the form of a 

initiates one of these special Library Processes, the work 25 database (relational, object oriented, etc.) or using a flat file 

request is first analyzed by the Primary ALM, in a Conven- system. Once a model is created and/or identified by control 

tional system, or an Actor ALM. The ALM algorithm information design libraries hold the actual pieces of the 

decodes the work request and calls upon our Library Process design under control of the system without limit to the 

Manager to direct it to the appropriate Remote Execution number of libraries, and providing for tracking and hierar- 

Machine. 30 chical designs which are allowed to traverse through mul- 

Our embodiment further enhances libraries arranged in an tiple libraries. Data Managers become part of the design 

Actor/Object configuration by contemplating the use of a team, and libraries are programmable to meet the needs of 

Dispatcher ALM. The Dispatcher is a special purpose Actor the design group they service. A control repository commu- 

which accepts job requests from the user and holds them nicates with users of the design control system for fulfilling 

until an Actor capable of processing that work request is 35 requests of a user and with data repositories of said data 

available to service it. Throughput is enhanced by ensuring management control system through a plurality of managers, 

all Actors are kept busy whenever possible, and the work- Each manager performs a unique function. Managers act as 

load is balanced across all of them. Configurations using a building blocks which can be combined in a plurality of 

Dispatcher identify the userid in the Library's Actor List manners to support an environment for suitable for multiple 

with a special entry denoting it as a Dispatcher. All fore- ^ users of a user community. 

ground algorithms which generate work requests check for As we review our concepts in greater detail, it will be seen 

this entry upon detection of an Actor/Object configuration. that the present embodiment describes a Data Management 

If it exists, the job request is sent to the corresponding System (DMS) which is composed of a suite of function 

userid. Otherwise, the Actor List is examined for the first managers and one or more projects (see FIG. 16 — Items 10, 

Actor in the list capable of servicing that request. The job is 45 11, 14, 15 and 16). Each project is composed of a central 

then dispatched directly to that Actor. If multiple jobs need Control Repository and one or more data repositories (see 

to be dispatched, the jobs are distributed to all the Actors, FIG. 16— Items 12 and 13) to store, manage, and manipulate 

capable of handling the task, in a round-robin fashion. This virtually any type of data object. The Control Repository 

scenario may lead to an unbalanced workload among several consists of a Common Access Interface and one or more data 

Actors if the job requests have a large disparity in processing 50 bases (see FIG. 17— Items 1 thru 5). These data bases may 

times. The Dispatcher is designed to eliminate this. be: 

The preferred embodiment permits any ALM to act as a A Relational Data Base consisting of a collection of tables 

Dispatcher simply by configuring the Autoreader to run a of data where the columns contain the attributes of 

special Dispatcher algorithm. It works on the premise that related data and the rows are the instances of the data. 

Autoreader permits three types of interrupts: 55 An Object Oriented Data Base consisting of a collection 

1. A new request arriving in the Reader causes a Pre Check of object instances of classes where the attributes are 
interrupt. the class members. 

2. A message or command may be used as an interrupt A Control File Data Base consisting of a collection of files 

3. AutoReader's built in timer acts as an interrupt when it where the records are the instances of data and the 
"wakes up". 60 attributes are arranged along the records. 

The algorithm continuously monitors for any type of A Directory Data Base consisting of a collection of file 

interrupts. Upon receiving one, it must check to see if it's directories which may or may not contain files. Their 

one of the three aforementioned types. There are other types relationships are described by the directory structure, 

of interrupts, but they don't pertain to the Dispatcher tunc- The instances can be either sub-directories or files, 

tion. 65 This repository communicates with users and the data 

Our preferred Design Control Repository and System repositories through a plurality of Managers, each perfbrm- 

Methods (5.0) ing a unique function. These Managers act as building 



12/23/2003, EAST Version: 1.4.1 



5,950,201 

67 68 

blocks which can be combined in numerous ways to support ascending Levels until all Levels in the current Version are 

environments ranging from a small user community to a exhausted. If the current Version is based on a previous 

global enterprise. Version, the search will traverse the previous Version. The 

Our preferred embodiment employs a relational database search engine will locate data stored on multiple platforms 

to serve as the Control Repository. Each data object in the 5 and a single invocation can find multiple data objects of the 

Data Management System (DMS) is assigned a unique identical or different data types. The Search Manager offers 

identifier that permits all information about the object to be a multitude of options and features to seek out data m public 

recorded and tracked by a multiplicity of relational tables. and pnvate Lforanes, to sort and filter the results, and to 

The physical data is stored using conventional storage %^^™ h ™ 

management techniques which allow any type of data (text 10 ^preferred Embodiment describes the most sopbisti- 
or binary) to be tracked in it s original form. Hie data may c ^ ^ of ^ DMS whfch incorporates a ta mmujnca . 
even reside on multiple platforms. tion Manager to manage aU communications with the Con- 
Users of the DMS communicate directly with the Control ^ Repository. It employs a series of communications 
Repository, through a Communications Manager, to initiate machines capable of queuing and prioritizing queries initi- 
some or all data management functions. Upon initiation, the 15 ate< j D y users or Automated Library Machines. The mecha- 
Communication Manager employs one of the other Manag- enables unlimited access to the Repository regardless 
ers to complete the task. Our preferred embodiment con- 0 f the number of simultaneous queries supported by the 
templates the use of software service machines, known' as * database. The Communication Manager also provides a 
Automated Library Machines, which execute requests on medium of information exchange for all other Managers and 
behalf of the users. These Automated Library Machines 20 the ALMs. Since the Communication Manager supports 
(ALMs) automatically enable the proper Manager to carry multiple platforms, it acts as an agent to provide remote 
out the desired task, while freeing up the user's environment access to the Control Repository through conduits such as 
to perform other activities. The Communication Manager mc Internet. 

also enables the ALMs to communicate directly with the The present embodiment provides data control and secu- 
Control Repository. 25 nty through a Lock Manager which offers three types of 
In order optimize data storage, our embodiment uses a locks. First, there are Out for Update or Ownership locks 
PFVL paradigm to identify all data in the DMS by Eackage, which permit a user to check out a data object and modify 
Eile Type, (Data Type), Version and Level. Packages are ft without fear of another user making a simultaneous 
arbitrary divisions of data whereby all the data has some update. Our embodiment also provides a means for trans- 
common association. A Data or Package Manager defines 30 ferring ownership of apiece of data from the primary owner 
the structure for the Package and performs all data manage- to a designated surrogate without the primary owner's 
ment administrative functions. Levels are typically associ- intervention. Upon completion of the transfer, the primary 
ated with "degrees of goodness" or quality. Data typically owner ^ automatically notified of the ownership transfer, 
enters the DMS at low Levels with minimum entry criteria. Additionally, the preferred embodiment provides an envi- 
As the quality improves, it is promoted to higher Levels until 35 ronment where multiple users can own the same piece of 
eventually being released as a finished product. Our system data at different Library Levels. 

supports robust promotion criteria definitions which may \ a addition to ownership locks, the Lock Manager offers 

exist for every PFVL in the DMS. versions allow multiple Move and Overlay locks which can be used to prevent data 

variations of the same piece of data to be processed and fr om being moved through the DMS or overlaid by the data 

managed simultaneously. One Version may be independent 40 at lower Levels. It also interacts with the Aggregation 

or based on another, which eliminates the need for common Manager to provide locking of entire an Bill of Materials, 

data to be repeated. and it interacts with the Process Manager to provide an 

The present embodiment expands the PFVL paradigm interlocking mechanism or data undergoing Automated 

into a means which enables the Data Manager to configure library Processing. 

a Package under numerous structural arrangements. For 45 Ou r embodiment contains an Authority Manager to pro- 
example, the Data Manager may store all the data into a v ide various types of user authorities down to the PFVL 
single physical repository, or segregate it by PFVL. The granularity. Interaction with the other Managers affords, but 
structure may contain multiple entry points, which enables js O ot limited to, the following authorities: 
data to be Fast-Pathed into non-entry Library Levels. This Data Promotion into and through public Libraries, 
feature supports unlimited branching where any Level may 50 Bm of Matcrial Promotion through public Libraries, 
have multiple lower Ixvels, each of whrich may have mul- q{ a rf 
uple lower Levels. Levels may be denoted Working Levels _ . . . ^ ... . t . . 
which constitute the minimum structure all data in a given Semn * me mree ^ ° f locks on ob J ects 
Package and Version must traverse prior to release. Working Initiating Automated Library Processes 
Levels are transitory places where no data resides perma- 55 Setting Level Independent Pseudo Process results 
nently. In addition, our embodiment permits the existence of Our embodiment even permits pattern matching on the 
Release Levels where data resides upon release as a finished names of the data objects to add another Level of granularity 
product. These can be Regular Release Levels where data beyond the PFVL - 

may only enter from the highest Working Level and remain lo onto to aid the Data Manager in performing the 

permanently frozen. There is also a concept of a Sideways 60 multitude of administrative tasks, our embodiment contem- 

Release Level which serve as a repository for modifications P^tes a Package Manager which includes utilities and user 

made to data residing in Regular Release Levels. interfaces to accomplish the following: 

In order to aid users and third party tools in locating data, Set up Package Control Data such as Fix Management 

our embodiment offers a Search Manager. The underlying and P/N Control Levels. 

utilities provide a means to search for data starting at a 65 Define or dynamically reconfigure the Library Structure, 

specified Level and Version. If the search fails to find the including selection of data types to be tracked under the 

data at the starting location, it will traverse the structure DMS. 
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Define the physical repositories of the data (down to the 

PFVL if so desired). 
Balance workloads among Automated Library Machines. 
Define, manage and edit: 

Automated Library Processes 5 

Authorities 

Automated File Groups 

The Package Manager supports Authority Profiles which 
permit the Data Manager to assign users to a classification 
and apply authorities to the entire classification. It also 10 
incorporates the concept of pre-defined process groups and 
templates which allow process definitions to be standardized 
across multiple packages. In our preferred embodiment, 
these definitions can be stored in flat files called Progroups 
or within a sample Package in the Control Repository. The 15 
Package Manager also offers a variety of report generators 
for information about installed Levels, Versions, data types, 
Automated Library Machines, process definitions, process 
results, authorities, fix management and release control 
information. Upon completion of all interactive editing, the 20 
Package Manager employs a batch commit process which 
converts the changes into a series of Control Repository 
modification instructions. 

Our Data Management System also employs various 
utilities to aid in performance tuning and automated recov- 25 
ery of the Control Repository, data archiving, Control infor- 
mation back-up, and a mechanism to generate performance 
tuning reports. 

Additionally the DMS employs a library Manager to 
execute all data movement, check out, manipulation, check 30 
in and deletion. It also contains a Process Manager to 
provide Automated Library Processing and External Data 
Control. Also present is a Problem Fix/Part Number/Release 
Control Manager to associate and track problems and part 
numbers to data as well as coordinate releases. Finally an 35 
Aggregation Manager is included for creating and tracking 
arbitrary collections of data objects. 

Structure and Search Manager 

The present embodiment incorporates a robust concept 
which permits a data management structure capable of 40 
tracking a plurality of data objects governed under similar or 
disparate processes. The concept is based on a paradigm in 
which all objects can be classified by Package or its syn- 
onym library, Type of Object (Our preferred embodiment 
denotes this as File Type), Version and Quality Level. This 45 
paradigm is hereafter referred to as the PFVL paradigm. (See 
FIG. 18 — Items 1 thru 7). Under this arrangement, a Pack- 
age is simply defined as a grouping of objects with common 
characteristics. In some environments, such as Chip Design 
or Software Development, a Package is referred to as a 50 
library. Commonality may be defined in numerous ways. 
For example, all the components in a Library may be 
members of the same higher level component (such as all the 
ASICs on a PC Board), and thus may be considered a single 
Package. Another example may be all the programming 55 
modules written by a particular software development team. 

Within a Package or Library, data is organized by Version. 
Versions allow parallel evolution of the same components to 
coexist in the same library. For example, two Versions of a 
Video Graphics chip may be developed in tandem, one for 60 
the PCI interface and one for VL-BUS. Our embodiment 
allows the two flavors of design to use the same object 
names, reside in the same Library, and even be at the same 
Level, simultaneously. 

For each Version, there is a Level Structure. In our 65 
preferred embodiment, Levels denote a degree of 
completeness, stability or quality control. The definition of 
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"degree of quality control" is left up to the Data Manager. 
Our embodiment simply affords the Data Manager a means 
to establish a Level structure commensurate with the goals 
and objectives of the user community. 

All data objects are identified by name and type. Our 
preferred embodiment depicts all objects as files, but they 
can be any type of object that exists in a computer environ- 
ment. The type of object serves as the fourth qualifier in the 
PFVL paradigm. In summary, an entity characterized by a 
single name may have multiple types of data objects, simul- 
taneously residing in multiple Levels, of multiple Versions 
and spanning multiple Libraries. 

In addition to denoting degrees of completeness, our 
embodiment permits Levels to be chained together to allow 
data to migrate from one Level to the next. Any or all of 
these Levels can be designated as Entry Levels whereby data 
may enter from a user's Private Library. Levels are also 
categorized as Working Levels or Release Levels. Data in 
Working Levels is transitory, and must eventually migrate to 
a Release Level. Release Levels serve as permanent storage 
vaults for a coherent set of data. Once the data is promoted 
into a Release Level, that Level is frozen and a new Release 
Level is opened Data always migrates from the highest 
Working Level into the current, or open, Release Level. Any 
Working Level may be promoted to from another Working 
Level, or serve as an Entry Level for data coming from a 
Private Library. Release Levels are more restrictive. The 
current Release Level can be promoted to, but can't be an 
entry point for outside data. Frozen Release Levels are 
neither entry points nor are they promotable. Our embodi- 
ment does provide a means to thaw a frozen Release Level 
and delete data from it. 

Our embodiment also discloses one special type of 
Release Level known as a Sideways Release Level. These 
Levels always branch out from a regular Release Level, but 
unlike regular Release Levels, data is permitted to enter 
from a Private Library. This arrangement permits updates 
and "fixes" to problems found with data residing in a frozen 
Release Level. 

The PFVL structure lends itself to a powerful feature of 
the embodiment known as a Library Search Engine. In many 
commercial Data Management Systems, the means for 
establishing quality Levels often require physical segrega- 
tion of data into a common repository. Usually this entails 
making copies of the data to multiple locations. Although 
our preferred embodiment will permit data to be copied as 
it migrates from one Level to the next, the default action is 
for the data to move to the higher Level. The Library Search 
Engine can be used to pick a starting location in the Library 
Structure and seek out a collection of coherent data objects, 
regardless of their current Library location or physical 
residence. The Search Engine and it's underlying algorithms 
are discussed in the Search Manager section. 

Now, in considering our Control Repository illustrated by 
FIG. 17 and our Data Repository illustrated by FIG. 18 in 
implementing our system, an embodiment of a database that 
is used includes IBM's multimedia DB/2, or the databases of 
Informix which allow image and audio fields instead of plain 
text. With this kind of database, represented by the databases 
in the drawings, in the Control Repository, one could have 
image or audio fields. So a user could do a library search for 
all red sweaters that match a photograph of some hot new 
fashion design, at or above the PI price level starting with 
the "Parisienne" version. (Hint: this scenario could be an 
implementation of our DMS in a large mail order clothing 
outlet which caters to Web shoppers. 

One can use a text database such as DB/2 as the Control 
Repository, combined with the mutimedia DB/2, or other 
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multimedia supporting database as a data repository. This 
would allow storage of the actual data, audio and images 
into DB/2 where the various pattern matching engines could 
be used, yet still allow the data to be "controlled" or 
managed using our techniques with the cheaper and simpler 
DB/2 (which really only needs simple textbased tables to 
work). 

By using a multimedia database (e.g. DB/2 version) as the 
control repository, one could perform "queries" using voice 
commands like: "Display the Fix Management Data for Part 
18F4475" or "Show me electrical checking results for all 
schematics at the Ql level". 

FIG. 19 illustrates an example Library Structure. To 
clarify the example, the overall structure is segregated by 
Library File Type with inverted tree 110 denoting the ASIC 
structure, and inverted tree 120 denoting the Firmware 
structure. To begin with, both trees have Working Levels 
WL1, VL1 and VL2 in common. These are known as the 
Default Levels and these would exist for all LFTs in the 
Library. Turning our attention to the ASIC structure, it has 
additional unique Levels known as WL2, WL3, CD1, CD2 
and CD3. This type of arrangement could be used to 
accommodate high Level design being done at the Default 
Levels, synthesized parts being processed on the WL2-WL3 
branch, and custom design being done at the CD1, CD2 and 
CD3 Levels, Although our embodiment permits data to enter 
into any of these Levels, the Data Manager controls the 
Entry Levels. In this example ASIC data may enter CD1, 
CD2, WL1 or WL2. 

The highest Working Level is VL2, and above that is the 
current Release Level known as AR3. Above that are frozen 
Release Levels AR2 and AR1. AR1 is the original release of 
the ASIC design, and AR3 will contain the most recent To 
the left of Release Level AR1 is Sideways Release Level 
ARP1. Additionally, Release Level AR2 has Sideways 
Release Levels ARP2 and ARP3. As stated above, when data 
enters any of the Release Levels except AR3, it is "trapped" 
and can't move to another Level. However, it can be located 
with the Library Search Engine. 

Since there are 7 entry points (CD1, CD2, WL1, WL2, 
ARP1, ARP2, and ARP3), there are 7 independent search 
paths. The user may initiate a search for data at any point in 
any of these 7 paths. A search initiated at a Working Level 
or regular Release Level will move towards the "tree trunk" 
and up to the oldest Release Level (AR1). The search path 
for CD2 would be: 

CD2-*CD3-*VL1 — VL2^AR3^AR2->AR1 
(terminator) 

Searches beginning at a Sideways Release Level will 



10 



15 



25 



30 



35 



40 



45 



The entire structure of every Library in the DMS is stored 
in tables within the Control Repository. These tables show 
information about each Level denoting attributes such as 
Entry Level, Promotable Level and the physical location of 
the repository. In order to improve performance and 
availability, our preferred embodiment permits this struc- 
tural information to exist in an external file for quick 
reference by users running applications in their Private 
Libraries. An example of a structure file is shown in FIG. 20. 

The structure file in FIG. 20 is divided into 6 sections. 
Each section contains the following four tokens: 

The first token contains three pieces of information delim- 
ited by a / in our preferred embodiment. The / can be 
used to parse the first token as follows: 

1. The LFT where XXX denotes ALL LFTs in the 
library. 

2. The Version where XX denotes ALL Versions in the 
Library. 

3. The Source Level where 00 is a special keyword 
denoting any user's Private Library. 

The second token is the Target Level 
The third token is a Put/Promote flag which decodes as 
follows: 

NN Source Level not Puttable/No Promotion Path from 

Source to Target 
NY Source Level not Puttable/Promotion Path from 

Source to Target 
YN Source Level Puttable/No Promotion Path from 

Source to Target 
YY Source Level Puttable/Promotion Path from Source 

to Target 

The name of the physical repository of the Target Level. 
This can be multiple tokens depending on the computer 
platform. 

Making use of parts of an existing Cadence TDM system 

Now having discussed PFVL as part of an AFS version, 
we note that among existing systems, Cadence docs not have 
such an AFS version, but does provide DM software which 
can run on a Sun Microsystems Workstation. We have 
concluded that the current Cadence system is insufficient for 
our complex needs. However, Cadence has an effective 
underlying command line interface for the TDM function 
which drives all TDM functions. This command line inter- 
face can be modified so as to incorporate it into our 
methodology with an AFS environment. 

Basically, our Data Management System needs to employ 
what we call the PFVL Paradigm. 

Remember to optimize data storage we use a PFVL 
paradigm to identify all data in the DMS by Package, File 



migrate towards the "tree trunk" then turn upward towards 50 Type, (Data Type), Version and Level. Packages are arbi- 



the oldest Release Level. A search beginning at ARP3 would 
look like: 

ARP3-*ARP2— AR2— AR1 (terminator) 

Turning our attention to inverted tree structure 120, this 
represents the Firmware tree. In addition to the Default 
Working Levels, this tree has Working Levels FD1 (which 
is an Entry Level) and FD2. It also shows Release Levels 
FR2 and FR1 (which is frozen). FR1 has one Sideways 
Release Level known as FRP1. 

Further unique structures can exist for each LFT in the 
Library, or an LFT can use the Default Structure. In addition, 
any structure may be replicated to form multiple Versions. In 
this way a single Library is equipped to handle a multitude 
of data management tasks. The only restriction on the 
present embodiment is that any given Level in the tree may 
migrate to one and only one higher Level. For example, CD3 
may not point to both VL1 and VL2. 
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trary divisions of data whereby all the data has some 
common association. The PFVL acronym was derived from 
IBM internal jargon, but the same principles can be applied 
using Cadence parlance as; 

Library — Variance — Quality Level — View — Cell — 
Version if our PFVL structure and principles are adopted, as 
they should be. The PFVL structure and process provides 
that every piece of data in the Data Management System 
(DMS), regardless of origin or importance, is tracked by 
PFVL In other words which our PFVL structure and prin- 
ciples are adopted in a Cadence system every piece of the 
design, whether it's a schematic, piece of VHDL, a layout, 
or documentation which is associated to a 

Library — Variance — Quality Level — View — Cell — 
Version has all of the data associated so that die system 
ensures every piece of data has the PFVL (here 6 attributes) 
associated with it 
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Furthermore, our DM principles state that all data and 
control information is tracked in an architecturally central- 
ized location consisting of a Data and Control Repository. 
An "architecturally centralized location" does not require 
that all the data must be kept in a single Unix directory, nor 
that all the control information must reside in a single 
metadata file. Nor does it imply the whole system must be 
governed by a single database. What is says is that the user 
must perceive the system in a manner by which all data 
appears to be tracked uniformly. So, an example might be 
that I have a design for an MPEG decoder. The physical 
design is done in Cadence so the actual layout data physi- 
cally resides in a "Cadence style directory structure". 
However, we have FrameMaker documentation which 
explains and diagrams the physical design, but as Frame- 
Maker documentation is done outside of Cadence, it is not 
stored originally as Cadence data. Physically this is kept in 
a completely different' Unix directory, maybe completely 
isolated by system and location from any "Cadence data". 
Using our system, however, wherever the documenation is 
located, the DMS still tracks both data objects by 

Library — Variance — Quality Level — View — Cell — 
Version which enables the user to do things like find/view all 
the data associated with the MPEG even if multiple pieces 
of data are in physically disparate locations. The reason this 
works is that the system ensures every piece of data has 
these 6 attributes associated with it. The control repository 
can also be distributed as long as each component follows 
the structure and process of the architecture. For example, 
the Cadence data to most quickly integrate our structure and 
process of our architecture into a Cadence system, one 
would use a routine for tracking the data by TDM using 
TDM*s control files to act as the Control Repository for the 
physical design of the MPEG decoder. Likewise, all Frame- 
Maker documentation might be tracked by a Lotus Notes 
Database so that it can be made available to both designers 
and external folks simultaneously. As long as the TDM 
Control Files and the Lotus Notes Database adhere to the 
PFVL architecture, the user is hidden from the inner work- 
ings. All he knows is that he runs some front-end script or 
GUI menu where he can ask to find all the MPEG decoder 
information under a given cell name at a particular Quality 
Level of a particular Variance in a certain Library. The DMS 
looks through the various physical Control Repositories, 
finds the layout and FrameMaker views, finds their exact 
Version numbers and locates them in the proper physical 
data repository. 

Our PFVL structure and process architecture should be 
used in combinatioS, with many other useful Data Manage- 
ment features which we have developed and explained. We 
feel the following features should tie universally imple- 
mented in combination with our PFVL structure: 

Using the PFVL architecture to set up a single logical 
Data Management system for design data (Cadence and 
non-Cadence). Various parts of the design are tracked in 
separate shared libraries. Each library would consist of N 
Quality Levels and M Variances (N and M are determined by 
each Data Manager based on the type of information stored 
in that library). 

Adynamic Bill of Materials Tracker would exist to allow 
PD, liming and Simulation Coordinators (Integrators) to 
easily identify all the desired pieces of a design at a 
particular Library, Level and Variance to be built into a 
"model". Once integrated into the model, the BOM Tracker 
would monitor the actual versions of the data objects and 
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alert the Integrator if any versions become obsolete. The 
BOM Tracker can also be used to perform promotions of 
cohesive units of data between levels. 
Automated Library Processing whereby tools, checks, 

5 and automated tasks can be launched either during move- 
ment of data between levels or while data is stable within a 
level. Results would be associated to the exact data objects 
used in the process (via the PFVL architecture) and retained 
in the Control Repository. These results can serve as pro- 

10 motion criteria to ensure data is promoted only when it has 
achieved the desired level of quality. The Data Manager 
would be able to "program" his library to run any available 
Library Processes either in a particular sequence or in 
parallel. 

15 External Data Control whereby results obtained from 
tools run outside of the DMS can be securely incorporated 
into the DMS with the same data integrity as an Automated 
Library Process initiated from within the DMS. 
A Locking mechanism which not only performs simple 

20 Check-Out, Check-in to assert ownership, but allows own- 
ership by PFVL. So, two different designers could check out 
different versions of the MPEG decoder at different Quality 
Levels. An example might be that the primary designer has 
the decoder checked out at the lowest library level, but the 

25 PD Integrator finds a minor electrical problem at the highest 
level which is causing a DRC check to fail. He simply has 
to insert a buffer so he goes ahead and checks out that level 
of the design, makes the change and checks it back in. He 
can continue with the DRC run while he informs the primary 

30 designer of the required change for the lower levels. This 
locking mechanism would also permit surrogate ownership 
of the same piece or design, such that two people would 
work on the same piece together. The system automatically 
ensures only one has it checked out at a time, but allows the 

35 other to "take ownership" if he needs to. Automatic notifi- 
cation and complete history tracking reduce the risk of 
miscommunication among the partners. In addition the 
locking mechanism would also support other types of locks 
such as Move and Overlay whereby coherent sets of data 

40 could be temporarily frozen into a Quality Level to prevent 
accidental movement or obsolescence while a lengthy model 
build is underway. 

Problem Fix Management and Engineering Change 
Tracking would provide various utilities to ensure that fixes 

45 to problems are contained within the proper EC. In addition 
certain information about the fix would be tracked in the 
Control Repository to enable various types of escape 
analysis, status reporting, etc. Mechanisms would exist to 
prevent or minimize the risk of the same piece of design 

50 being associated with multiple ECs or a piece of design 
being attached to the wrong EC. 

There are many other features of our preferred embodi- 
ments which we could employ, but we need to implement 
these concepts and we have working algorithms which we 

55 have provided in these applications which are suitable for 
use with TDM and some of TDM's existing features, like 
policies, can be employed as part of a foundation for our 
system. However all our algorithms expect the Control and 
Data Repositories to follow the PFVL architecture. Hence 

60 implementation needs to ensure use of things like hierarchial 
projects to properly emulate Quality Levels. We also need to 
ensure that Variances can be supported with the current 
TDM architecture. In order to use the systems together, at 
some point a conversion needs to provide the following 
mapping: 
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library - Variance - Quality Level - View - CellName - Version (Cadence) 
A A A A A A 
\! \/ \/ \/ \/ \/ 

Vfersion - Quality Level - Type - FfleName - I tend ion (IBM DMS) 



Id other words we need to be able to use the TDM API to 
make queries about data using the above mapping, between 
PFVL attributes, regardless of name or origin, as the data 
may originate in IBM DMS, Cadence, ViewLogic (see 
below) or elsewhere. 

Both private and public libraries need to be provided. 
With respect to private libraries Cadence employs Working 
Areas (a limited kind of Private Library) in which a user can 
define one or more private libraries, each of which can reside 
in any physical AFS location desired by the user. All 
authorities are are done'through AFS, so the user controls 
who can access or update their private areas. There is a GUI 
which makes it easy for a user to set up a Working Area and 
create private libraries. TDM includes a special Integration 
Area (a limited kind of Public Library) which is designed 
specifically for people performing coordination or verifica- 
tion tasks. These areas are similar to the regular working 
areas in terms of how they are defined, but these have 
additional functionality which is further discussed with 
regard to our Library Manager. Private libraries are a func- 
tion of our own library management system. With regard to 
public libraries, Cadence's TDM uses a Project Manage- 
ment tool to assist the Data Manager in various DM tasks 
such as defining and maintaining public libraries. The DM 
may set up an unlimited number of Release Areas, but the 
system is limited and only permits one Integration Area per 
public library. Furthermore, the DM also has no control over 
the initial physical location of the data (in the Integration 
Area or Release Areas), and the system automatically 
imposes a single directory tree structure for the public 
library. We note that within AIX is a function called 
"permissions**, and when TDM could be run in an AIX 
environment, when data must be relocated to another physi- 
cal repository, there is a TDM command to perform the 
function. In such an environment, since all authorizations 
would be done via an AIX permission, the DM would have 
complete control over file access, write authority, and data 
removal. 

There are several significant problems with this TDM 
system area of public and private libraries. The current TDM 
system fails to differentiate betweeo a Working Area, an 
Engineering Area, a Level Area and a Release Area. In 
complex development projects, these are different and each 
of these area must be differentiated by any concurrent 
engineering staff. TDM makes it impossible for the DM to 
define any type of library structure with multiples levels 
and/or versions. One could try to change the use of a Release 
Area to mimic an engineering level, but the required amount 
of daily iteration combined with the required degree of 
parallelism makes this impractical in a commercial environ- 
ment. Integration Areas may be considered as having 
adequate characteristics to serve as a model for engineering 
levels, and data can be continually promoted into the Inte- 
gration Area until such time that the Integrator feels it should 
be released. However, TDM is restricted to a single Inte- 
gration Area per public library. This may be compared to our 
own public library methodology which permits multiple 
Integration Areas per public library. Without this function, 
along with others which we may note, which needs to be 
implemented in the system as we have described it, TDM 
would not satisfy necessary requirements of a complex 
system. 



A complex system requires the ability to define data types 
and perform nongraphical DM tasks. We note TDM offers a 

10 powerful selection of data management commands which 
enable a Data Manager to do virtually an entire job from 
outside of the Cadence TDM system. TDM's command line 
API interface allows, for instance, any existing BOM appli- 
cation to run entirely in a system command line environ- 

15 ment. This allows for integration with nongraphical tools of 
third parties. This also provides the basis for data managers 
to write unlimited utilities (via C programs, shell scripts, 
perl scripts, etc.) to automate or enhance their productivity.* 
But we note that Data Types must be selected from a list of 

20 master cell views administered on a project wide basis. It is 
not evident that users can create a unique new Data Type 
themselves, even though they can create new data and select 
from existing Data Types (cell views). Apparently, also, 
non-Cadence data can't be tracked by an existing Library 

25 Browser. Library processing, particularly private library task 
launching is an aspect of our own development In this 
regard, Cadence offers the concept of Policies to permit task 
launching against any data object in the DMS. With proper 
arguments, we believe that any executable code could be run 

30 from a policy. This would permit a user to call a system 
function, third party tool, shell script, perl script, C program, 
etc. from within a policy. For conversion of an existing piece 
of code to a policy, an appropriate API code would be 
required. 

35 TDM has commands which can be invoked from a 
command line, within a script, program, or policy. This 
flexibility in the policy architecture of the tools when 
coupled with the set of TDM data management commands, 
does present the opportunity to combine our own develop- 

40 ments with this aspect of TDM. While TDM invokes a 
policy from a TDM session, it is possible to launch a policy 
from an AIX window. To incorporate our developments, 
there would need to be tight integration of policy launching 
from a Library Browser like that we have in our library 

45 management function discussed below (although we note 
that Cadence provides a library browser without our 
functionality). 

We note that policies can be chained together such that a 
policy sequence can be run. However, the sequence in TDM 

50 is not determined by the Data Manager or user, but rather by 
sorting the policies in alphabetical order by name, then using 
that as the order of execution. Policies can be configured to 
launch during other DM operations, such as Check Out or 
Check In, or they can run stand-alone. 

55 Public library task launching is required. In this regard, 
TDM provides that all policy functions are available to a 
Working Area (b, Private Library) and also available to data 
in an Integration Area or Release Area (Public Library). The 
existence of a fully functional command line interface in 

60 TDM allows the Data Manager or Integrators to perform a 
variety of tasks, without invoking a separate Cadance tool 
call Framework. 

Cadence also has a separate tool product PCS which 
allows one to graphically diagram a process flow. The user 

65 simply clicks on the various process boxes, and the tool then 
executes underlying policies. This provides a nice graphical 
interface to assist designers who prefer working with GUIs. 
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Basic design tasks and library promotion is handled by 
our development's library management system and Library 
Browser. In this regard, TDM uses a Working Area 
-to-*Integration Area -to— ^Release Area paradigm as their 
basic design control flow. By mapping between their model 
and our model of designer library -to-^working library 
levels -to— ^release levels, there is a close correspondence. 
The Cadence submission facility corresponds to a promotion 
utility for moving data from a Working Area to the Integra- 
tion Area, and from the Integration Area to the Release Area. 
The TDM front end allows one to perform Check Out, 
Check In, Promotion, Switching work areas, and viewing 
Integration areas. However, the user interface for the Work- 
ing area is inadequate, and does not serve as a Library 
Browser replacement 

The latest 4.4 Version of TDM is not capable of checking 
data out of public libraries, checking in, promoting to 
integration and release' areas, displaying and browsing data 
in integration and release areas and easily switching between 
multiple working areas. In the Cadence framework, all 
designer functions need to be executed from the library 
browser, and the subset of data management commands used 
on a daily basis should be supplied, as this is an absolute 
requirement for our complex design systems environment 

The Cadence system does not, as does our development, 
supply multiple "integration areas" and our complex design 
systems environment does require multiple working library 
levels. Apparently, standard opinion is that one could use a 
shared integration area in order to keep a complex part, e.g. 
an E-Unit in the same library. What has not been appreciated 
with an Element and System Sim sharing the same integra- 
tion area, is that there is invariably a phase shift in build 
frequency. This makes the assumption of this prior work 
impractical, for they should not and do not always co-exist. 
Thus there is a need for our multiple integration areas and 
these need to be properly addressed to successfully imple- 
ment a complex design control system. 

Furthermore, our library management system, as we 
discuss, provides for extracting data from a public library. Io 
our methodology both the integrators/coordinators/model 
builders and the designers need simple access methods to 
data in release areas. 

The prior art has treated releases as a static configuration. 
Thus, the Cadence TDM concept of a Release is a complete 
set of pointers to each component of an entire design, 
something akin to a Bill of materials, a static configuration. 
Release Areas always contain pointers to every piece of 
design. This makes model builds in the single Integration 
Area very straight forward since the integrator need only 
point to a Release as a starting point, then incrementally add 
in designer's updates and fixes. To do this the integrator 
must use a separate tool suite, which is awkward But, as we 
have discovered, the designers) needs to access released 
data. The absence of such function would be catastrophic in 
a complex system design environment. With the current 
Cadence product, the designer is forced to use the TDM 
front-end to perform basic data management functions such 
as switching/viewing work areas, checking data in, checking 
data out, promoting data, and accessing integration and 
release areas (public libraries). In fact, in the Cadence 
system, it is easy for a user to accidentally point to and edit 
a design's control data, instead of the design itself. The risk 
of designer error thus is unacceptable. 

This is solved by our development by providing a way to 
sort data by cell name, or cell view, with a tree structure 
display, categories, etc. A user has, and should have, no 
access to control and meta data. Use of a prior art system 
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which could require a designer to ping-pong between an 
unsatisfactory library browser and a rudimentary front-end 
is risky and unacceptable. 
Nevertheless, in fairness, we would say that we could run 

s typical design DM tasks non-graphically with the set of 
TDM commands coupled with a command line interface to 
permit any of the basic design functions (Check out, check 
in, promote, view work areas, view release areas) with the 
capabilities of an operating system like AIX. From an AIX 

10 command line, using script, or any type of executable 
program, this part of DM can be performed in such an 
environment. 

Our system provides a way for sharing/transferring data 
ownership. In this system, file locking mechanisms are 

15 present Cadence's TDM offers two methods for locking 
files during checkouts. The first is an exclusive lock (the 
default) where check out of any version of a design com- 
ponent renders all other versions of the same component 
unavailable for editing. There is a problem with this 

20 solution, in that it not only prevents a second designer from 
updating someone's components, it also prevents the origi- 
nal owner from working on two versions of the component 
simultaneously. For example, if a bug is found in the 
Element and System sim models, and they contain two 

25 different versions of a component, the designer must check 
out, fix, and check in each version sequentially. 

Cadence also has a method using non-exclusive locks, 
whereby two different users may check out different ver- 
sions of a design simultaneously. Again there is a problem 

30 with this solution. Since the system won't allow the same 
user to hold two non-exclusive locks on the same piece of 
data, in the aforementioned example of an Element and 
System sim design bug, sequential fixes are still required 
(unless the original designer gets a second user to fix one 

35 version of the design while he fixed the other, sometimes a 
problem when the original designer is in the USA and the 
second designer is in Japan or Germany, France, England, 
Canada or one or more of many other countries, to indicate 
a real possibility). Furthermore, there is a possibility that a 

40 second user can grab and modify a different version of the 
design without the original owner ever knowing about it. 
The result is a system which has no utility for transferring 
ownership, as we have provided, making it difficult to 
operate on different versions of the design in parallel as 

45 required for concurrent engineering. Furthermore, depend- 
ing on the type of locking employed, with TDM it may not 
be possible for another designer to act as a surrogate for the 
original designer in an emergency situation (i.e. Where the 
original designer has the file checked out and has to unex- 

50 pectedly take a leave of absence). The TDM system does not 
permit the DM to override or reset a designer's check out 
locks. 

Our system, we will note here, has a locking mechanism 
which enables transfer of ownership permanently or 

55 temporarily, and allows for an override or rest of the check 
out locks, and provides notification to the original designer 
or administrator in the event of check out 

A system requirement in this kind of system is a Bill of 
Materials (BOM) mechanism which should have a satisfac- 

60 tory way to create BOMs, as we have provided. The 
Cadence Checkpoint Manger provides a nice mechanism to 
create Checkpoints (BQMs). Checkpoints are manageable 
data objects, which means that they can be checked in, 
checked out, promoted and tasks can be run against their 

65 members, the Cadence system permits Checkpoints to con- 
tain other Checkpoints as members, thus allowing hierar- 
chical creation. All Checkpoint information is stored in an 
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ASC file, which, coupled by the TDM command line API 
interface, permits the TDM to interact with third party tools. 

Our preferred embodiment, it will be noted permits lock- 
ing a Bill of Materials. In this regard, we note the TDM 
makes it possible to save all versions of a design component 
and use pointers to denote which version is associated to the 
Integration Area or a Release Area. However, it appears 
possible to delete a version, and no mechanism exists for the 
Coordinator to "lock down" the versions of his model to 
prevent this. No mechanism appears to exist to prevent 
newer versions from entering the Level at which the Coor- 
dinator is working, therefore he can't always be assured of 
working with the most recent data. However, with knowl- 
edge of the way we provide for locking a Bill of Materials, 
one could modify the Cadence TDM paradigm to accom- 
modate lock down. A coordinator would first build some 
type of model, and create a Checkpoint to track the contents 
of the mode,. After the model is working properly, it could 
on a later day be declared a success. During the time the 
Coordinator first ensures none of the member; of the model 
disappear (are deleted or overlayed) and ensures that they 
can't be accidentally promoted to another level. Secondly, 
the Coordinator would be enabled to know if, on the later 
day, if any of the members of the model have become 
back-level. This may be achieved by a Cadence "policy" 
solution, where a policy code is written to set a "freeze" flag 
against each member of a checkpoint This would be satis- 
factory. 

One of the features present in Cadence's Checkpoint 
Manager is that the BOM can be static (which means the 
contents are a snapshot version numbers) or dynamic (which 
means the contents change to always include the most recent 
version of a component). Adding or deleting members of an 
existing BOM is relatively easy. We also update members of 
a BOM in accordance with our preferred embodiment. 

It will be noted that we have addressed the issue of 
gathering BOM status or real-time BOM invalidation, some- 
thing not possible with such tools as provided by Cadence. 
Furthermore, we can use the BOM as a handle to promote 
the updates into an Integration or Release area from the 
Working Area. In addition, we provide "real-time" notifica- 
tion if members are deleted or modified. This capitalized on 
the ease in updating and deleting members in the BOM. 

It will be noted that we provide utilities for examining 
BOM operations. In the Cadence system, the owner can 
delete the Checkpoint without affecting the data objects, but 
there is no convenient method for viewing the status of a 
BOM or its members. 

We have provided a convenient set of utilities for use an 
examining BOM operations. We provide a method for 
viewing the status of a BOM or its members. With our 
provisions, in a TDM system, not only could an owner delete 
the Checkpoint without affecting the data object, but task 
launching could be built in for BOM members. To launch 
tasks in a cadence system, a Policy could be written to loop 
though the members of the BOM and either launch tasks 
against them or determine their current version is most 
recent. Our method for BOM movement through a library is 
a substantial advance. Cadence's TDM has no BOM pro- 
motion mechanism. 

We have described how we provide for BOM movement 
through a Library. Our ideas could be implemented in a 
Cadence like system, when our ideas for multiple integration 
levels are incorporated, by using the underlying Cadence 
Checkpoint mechanism to move BOMs through the library 
levels. 

We have provided for program fix management, another 
substantial advance. TDM has no built-in fix management 
function. 
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Cadence policies can be used to achieve our problem fix 
management functions. The mechanisms which we use to 
implement the tasks should be used. 
Our release manager enables making design changes for 

5 subsequent releases. The TDM model of moving Integration 
-to-* Re lease area supports initial releases and sequential 
ECs well. Subsequent releases are constructed using any 
current release as a base and the sole Integrator has complete 
control over the Integration -to-*Release Area path. The 

10 Data Manager can define any number of release areas, 
control access, and has complete freedom of nomenclature. 

Cadence's TDM lacks any inherent concept of multiple 
level structures within a given project. Although Integration 
Areas can serve as a single level, it does not permit the 

15 establishment of seperate engineering and release levels 
with the ability to physically segregate the data accordingly. 
Also, in this connection, we note that the Data Manager 
can't define any physical location of released data, and TDM 
automatically assigns new Release Areas to a directory 

20 hanging off of a top-level directory for the entire Library. 
Data can be displaced by a relocate function. Evei^hing for 
project management is sequential. With the Cadence system, 
multiple versions cannot satisfy the parallel developments 
required for concurrent engineering. 

25 As we would note, our release manager allows the cre- 
ation of multiple "Integration Areas" making it possible to 
run multiple ECs or Design versions in parallel. We can 
define the physical location of released data. This is impor- 
tant in large volume design components which require 

30 extensive ECs. 

With our release manager, ECing a released component is 
handled. This task resolves around a designer accessing a 
released piece of design, modifying it, and then releasing it 
under a new EC With TDM a designer via the user interface 

35 can open a Release Area and check out a piece of data into 
any V\brking Area. This allows a designer some flexibility in 
setting up multiple Working Areas or private libraries for 
different ECs. However, the users are subjected to the 
failings of the TDM user interface. Most frequent DM 

40 problems occur when a designer mistakenly sends a com- 
ponent into the wrong EC stream. While with TDM, where 
only one EC is processed at a time, one could minimize this 
problem by having a single Integration area for a Public 
Library, but this requires the Integrator to ensure that he 

45 selects the appropriate target Release Area and handle the 
Integration Area -to-»Release Area promotion himself. Mix- 
ing components into the wrong EC stream is possible and 
risky. 

With regard to ECing a released component, multiple 

50 Integration Areas could be provided and coupled to manage 
data from multiple ECs. It is possible to iterate and verify 
parts with Multiple Integration areas. However, one still has 
to properly implement the DMS to avoid having a part from 
different ECs mixing together, so our Design Control Sys- 

55 tern if building models needs to be implemented. 

Io our Design Control System we allow building models 
from released data, This tasks requires Integrators to be able 
to easily access all components relating to a Release, and 
perform tasks such as netlisting a release. TDM has a single 

60 Integration area, and the Release is a pointer to a complete 
set of design components, but there is no library browser 
support since some model build task may require launching 
tools from within the framework. TDM has no support for 
multiple Integration areas, making it impossible to perform 

65 multiple model builds in parallel. We discuss how to fix 
design problems in multiple releases within our system. It is 
not possible with TDM to make simultaneous fixes. A user 
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is unable to Check out multiple versions of the same piece exact data objects used in the process (via the PFVL 

of design, even though the Release area structure does architecture) and retained in the Control Repository; 

permit a Data Manager to establish area for "patches" to (e) providing External Data Control whereby results 

Released data (i.e. design patches for the test floor obtained from tools run outside of the DMS can be securely 

With the Design Control System it is possible to conduct 5 incorporated into the DMS with the same data integrity as an 

an ISO approved verification audit, Cadence has no way of Automated Library Process initiated from within the DMS; 

conducting an ISO approved verification audit as a task, so ^ providing a Locking mechanism which not only per- 

adoption of our our process management function and our forms ^mpte Check-Out, Check-in to assert ownership, but 

release manager methods needs to be employed. aUows ownersh j p by PFVL, so, two different designers 

An ISO approved verification audit requires a ISO Quality 1Q coukJ check QUt different versions of the piece of a design 

Record. This task requires a DMS capable of storing results elemenl at different Quality Levels; and 

from tasks along with the proper pedigree information for ^ providing Problem Fix Management and Engineering 

the files used to run the tasks. It can then be enhanced to change Tracking which would provide various utilities to 

produce output in a comparable format to the ISO Quality ensure mat fixes to pro blems are contained within the proper 

Record In this connection wc use our process management 5 £q 

function and our release manager. Now> whcn onc rcv i C ws the ViewLogic product, we can 

Making use of parts of an existing ViewLogic system ^ our Qwn pcrspcctive> interpret the ViewLogic Working 

- As we will discuss vanous changes which need to be ^ aWc to ^ ft Ujhm 6 f Private Libraries, 

adopted for existing software in order to make use of part of Users must be aligned t0 the "Team" by the Data 

that software in our new environment, we note that View- 2Q Maoager mey exis( on a Team> mey may create as 

Logic provides software tools for Unix type workstations, many Working Areas as they desire, and they can locate 

such as the preferred AIX version which is capable of them anywhere in the directory structure of an AFS system, 

running in an AFS environment Again, we believe that the ^ permissions serve as the only means of authorization, 

current ViewLogic software, which is now insufficient for ^ ^ user has ^pfete control 0V er who has access to their 

our complex needs, needs to be changed. M daU ^ Working ^3 ^ ai ways driven by the existence or 

ViewLogic's View Data is based on ASC files which can absence of the physical files. This means data can always be 

be edited and viewed and easily maintained. Nevertheless, Cfcatcd 0f dckted from outsidc of ViewLogic's ViewData, 

our PFVL structure and principles need to be adopted, and ^ Working area ^ guaranteed to provide an accurate 

whether aspects are called image 

Package— Vision— Quality Level— Type— FileName— 30 Unfortunately, while it is easy for a user to create multiple 

Iteration (IBM DMS) or Working Areas, the ViewData DMS has an awkward user 

Library — Variance — Quality Level — View — Cell — interface for managing multiple areas. For example, the user 

Version can't display all the files in multiple areas at the same time, 

or some other name, version, level, type, filename, iteration They must switch between Working Areas via a Set Envi- 

structure if our PFVL structure and principles are adopted, 35 ronment function, which does not provide adequate visual 

as they should be. The PFVL structure and process provides cues to assist the user in knowing where they are currently 

that every piece of data in the Data Management System , pointing to. This makes it difficult to use and adjust to. 

(DMS), regardless of origin or importance, is tracked by The ViewLogic's ViewData uses a Team paragigm to 

PFVL. In other words which our PFVL structure and prin- perform shared data management. This is somewhat analo- 

ciples are adopted in a Cadence system every piece of the 4^ g 0US to a Public Library. Each Team may have any number 

design, whether it's a schematic, piece of VHDL, a layout, G f Release Areas, and members of a Team. Each member 

or documentation which is associated to a may have unlimited Working Areas. The DM can create 

Package — \fersion — Quality Level — Type — FileName — Release Areas, specify the physical location of the data, and 

Iteration (IBM DMS) or rename or delete the Release Area at any time. While 

Library — Variance — Quality Level — View — Cell — 45 ViewData can be flexible in creating Release Areas, the 

Version architecture does not differentiate between levels. A DM 

or some other name, version, level, type, filename, iteration can't define the type of structure required for concurrent 

structure has all of the data associated so that the system engineering with multiple levels. Promoting data between 

ensures every piece of data has these 6 attributes associated Release Areas is not adequately addressed. Furthermore, the 

with it. 50 architecture requires the user to only permit the user to look 

Here we would recommend ViewLogic adopt our DMS at data in one Working Area and one Release Area at a time, 

including There is no way to look at data, in all Release Areas 

(a) our DM principles state that all data and control simultaneously. All data is stored in a Vault during a Check- 
information is tracked in an architecturally centralized loca- In operation. Since data can be checked in while residing in 
tion consisting of a Data and Control Repository; 55 a Working Area, or during a desired promote to a Release 

(b) using the PFVL architecture to set up a single logical Area, the Library View imposes the restriction that a user 
Data Management system for design data (ViewLogic and must use the Set Environment function to point to a Working 
non- ViewLogic); Area and one Release Area. The view refreshes to show a 

(c) providing a dynamic Bill of Materials Tracker to allow union of all the data in those two repositories. If the user then 
PD, liming and Simulation Coordinators (Integrators) to 60 wants to see data in a different Release Are, they must again 
easily identify all the desired pieces of a design at a use the Set Environment. Since there is no way for the user 
particular Library, Level and Variance to be built into a to look at all Release Areas simultaneously, even the sim- 
" model", eta; plest DM maintenance and debug tasks (which are easy in 

(d) providing Automated Library Processing whereby our system) in ViewData are a virtual nightmare, 
tools, checks, automated tasks can be launched either during 65 Furthermore, the concept of unionizing data between a 
movement of data between levels or while data is stable Working Area and a single Release Area causes problems 
within a level and where results would be associated to the which is solved by our system. 
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MewData could be modified through the use of an RCS 
version Segregation to create "virtual" levels and Versions 
according to our teaching. This would be very similar to how 
we use static configurations today as virtual Levels. 

ViewLogic's Data Management functions can be per- 5 
formed from within their GUI or by updating ASC files 
which hold all the Library Configuration information. The 
ViewData DMS allows one to work with data imported from 
outside the ViewLogic environment. We have copied a 
Cadence symbol from one of our designs into a ViewLogic 10 
subdirectory serving as a Working Area. By simply refresh- 
ing the Library View, our Cadence symbol appeared as a 
new data object with a visual cue indicating it is in an 
unmanaged state. Thus we have shown that the existing 
viewData tools allow the end users to have the power to is 
define new data types by simply creating them or copying 
them into their Working Areas. This can be done via the GUI 
and by selecting the Data Type from a list of Data Types 
defined by the Data Manager for the Team. 

With regard to our private library task launching part of 20 
our preferred embodiment, we note that we could use 
ViewLogic scripting language known as ViewScript to pro- 
vide for any command line activity to be launched from the 
Libary Viewer. A built-in API permits tasks to be chained 
together, and ViewScripts can be written to test the results of 25 
one task before proceeding with the next task. All task 
launching is controlled by a single ASC file which may 
reside in a centralized location for a project, or each user 
may have their own. Within this file, the user may use the 
API to launch a task such as MTI Compile a stand-alone 30 
view script which may be simple or compiles, and imbed 
actual ViewScript code to do more complex things such as 
chaining tasks together with dependency. Once the file is 
saved, the new task appears in a task menu within the 
library Viewer. It is simple enough that users of ordinary 35 
programming skill can launch bottom line commands in 
accordance with our modification. 

With regard to our public library task launching we would 
note that all the task functions available to a private library 
should also be available to a public library. However, our 40 
experience is that ViewLogic does not provide any such 
function, although, theoretically they must know how to 
enable this function. However, ViewLogic has no distinct 
command line interface, and therefore the graphical View- 
Data product must be invoked momentarily even if the intent 45 
of the user is to launch a task which can be run non- 
graphically, such as a CLSI compile. 

With regard to our Design Control System's basic design 
tasks and library promotion ViewLogic's Mew Data is not 
suitable for concurrent engineering in which: designers only 50 
perform a limited amount of verification before sending data 
to a public or shared library; 

designers frequently need to work with back-level data; 

people 'performing verification frequently require shared 
access to all parts of a design; 55 

designers may have to work on multiple versions of the 
design in parallel; 

designers may "own" many design components; 

designers may share pieces of the same design (i.l. A 6u 
logic designer writes VHDL, and a circuit designer 
creates layout), and 

designers may belong to multiple "Teams'*. Within View- 
Data's design environment a user tends to work on an 
isolated piece of design, belonging to a single Team. In 65 
this paradigm the user tends to reside in the same Work 
Area and iterates within their private library until the 
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design is stable enough to be "released" into the public 
library. This paradigm assumes an orderly sequential 
design flow where the user is only interested in working 
within the latest version of design, and rarely needs to 
access back-level data. The designer is assumed able to 
perform all the necessary task with little need for data 
sharing. Within this limited structure, the ViewData 
system provides the necessary tools to edit, update, 
verify and release the design. 
However, when faced with a concurrent engineering 
approach, many of the needed characteristics simply don't 
exist in the ViewData product. For example, once a designer 
performs a Set Environment to point to the proper Working 
Area, its possible to browse and edit any data residing in that 
Working Area; however, if a designer needs to work with 
data in a different Working Area, he must switch the envi- 
ronment. This makes it impossible to see all of a designer's 
data simultaneously. 

The ViewData system requires the designer to Check Out 
a piece of data in order to edit it. This is the correct 
implementation, however, the system further employs the 
restriction that data must be checked out (owned) by the 
designer to simply browse the data. This is true whether the 
design is an isolated text file (like VHDL), or has hierar- 
chical dependencies (schematics). Basically the user must 
check out all components of a schematic in order to properly 
browse the schematic. This makes it difficult and impossible 
to share pieces of design or employ scenarios where multiple 
people anywhere need to debug a problem. 

ViewData's library browser uses a pair of icons to rep- 
resent the state of a data object The icons clearly indicate 
whether the curreot version of an object is managed or 
unmanaged, and whether it's up to date or obsolete. The 
system has built in safeguards to prevent a back level piece 
of data from accidentally being promoted. However, in our 
concurrent engineering approach, we solve the need to 
promote back-level data at required times, so the lack of this 
capability in ViewData's design is a detriment of this prior 
attempt. 

ViewLogic's Work Area approach imposes constraints on 
design which are unacceptable from a concurrent engineer- 
ing point of view. Data is automatically sorted by class (Data 
TYPE) as opposed to design component names. There is no 
way to re-sort the data. As a preferred concurrent engineer- 
ing approach useable under our design control system can 
and should be based on workiog with all types of a given 
component, use of a ViewLogic system to implement this 
approach would become cumbersome for designers owning 
many pieces. The visual clues provided by the ViewLogic 
system for indicating which Work Area a user is currently 
pointing to are insufficient. If a user has multiple Work 
Areas, it's too easy to begin working in the wrong area and 
not realize it. Furthermore, the Set Environment can switch 
back to a default setting without the user knowing a switch 
occurred. This creates numerous problems if the user is in 
the midst of editing a check out piece of data, and then 
checks it into a wrong Work Area by accident. An when the 
designer is unaware, a concurrent user cannot be aware, and 
so could later check out the piece of data placed in a wrong 
Work Area by accident, and further compound the problem. 

Our concept of promoting data from a Private to a Public 
Libary in the ViewLogic environment has similar problems. 
For example, the user must be pointing to a proper Work 
Area/Release Area union (using the Set Environment 
function) BEFORE initiating a "promote". The act of pro- 
moting a file in ViewData is called a Check In and Release, 
which consists of simply clicking on a menu pick. Since 
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there is no user interaction, failure to set the proper Work We provide for sharing/transferring of data ownership. 

Area/Release Are union results in a promote where data is Within the ViewLogic system the only means for formal 

either taken from the wrong source, deposited in the wrong transfer of ownership is the act of one user checking a file 

repository, or both. The user may never know this occurred. i°» followed by a second user checking it out. This system 

There is no means to perform an automated hierarchical 5 thus is not adequate for concurrent engineering because it 

promote where the user points to a top level schematic, and relies on personal communication aod coordination, 

the DM system automatically traverses the design to gather Furthermore, suppose, as happens, two users have different 

all the instantiated components. ~ versions of the same design component checked out for edit 

Another major issue making ViewData an unacceptable simultaneously. Because one was not aware of the other, 

substitute to our Design Control System is the absence of a 10 until l{ comes time for one user to promote his modification 

method for promoting data between Ubrary Levels (Release a Public Library, a problem will arise. However, even 

Areas). The ViewLogic DM system does not support this when the user has promoted his modification into a Public 

concept in a suitable manner for integrated design control. In Library, that user does know that someone has another 

ViewData, promotion of all data from Level A to Level B version check out, but is unable to find out which other 

requires a user to check out all the data into a Working Area, is version and who has it locked out This is not a trivial 

switch environment to a new Level, and perform the Check problem, because in a concurrent engineering environment 

In and Release function. In addition to being cumbersome different users constantly need to update the same piece of 

this is not possible under certain situations. Since check out desi g° * differnt levels without any knowledge of another's 

implies acquiring ownership, this means the Data Manager actions. The result is a loss of data integrity, 

must be able to get ownership of all the data at Level A. If 20 We provide a built-in utility to transfer ownership, notify 

a designer in a concurrent engineering environment is in the one user tha another requests ownership, and provide a 

middle of an update, this is not possible with ViewData. facility to monitor who has various versions of a design 

ViewLogic needs to have the ability to sort the Library checked out at any point of time. Our solution provides a 

Viewer by design component, something now absent in the foreman mechanism allowing multiple versions of a data 

ViewLogic system, yet one which we have provided. 25 object to be updated simultaneously, with multiple owner- 

We provide for extracting data from a Public Library; snips and notification being handled as appropriate for the 

however, the ViewLogic DMS has no adequate substitute tas ^- 

function. In the best case, with ViewLogic, the user must We note ^at running ViewLogic DM functions or tasks 

perform a Set Environment function and establish a proper can performed oongraphically in a way accommodating 

Work Area/Release Area union before any data can be 30 our own design control system, making changes to follow 

extracted from a Public Library. Thus a user needs to have our preferred embodiments possible, 

knowledge of which Work Area was used as a source of Regarding a comparison of the viewLogic system, with 

promotion into the Release Area, something not assumable foe manner we employ for creating a bill of materials, 

in an integrated concurrent engineering environment. As a ViewLogic DMS offers the concept of a Collection and a 

single data object promotes though multiple Release Areas, 35 Checkpoint. The difference is that a Checkpoint is a static 

it gets more difficult to understand the association. The snapshot of a coherent aggregate of data objects identified 

Library View can display all existing versions of an object, b y exact version numbers, analogous to our Bill of 

but nothing in the system indicates which version is cur- Materials. A ViewLogic Collection is a grouping of data 

rently residing in which Release Area. Furthermore, the only objects where each oject in the group is always the latest 

type of sorting is by Data Type, so all levels of a schematic 40 version. The purpose of a Collection is to act as a "handle" 

are mixed together. In short, the only means a user has of DV wnicn toe can Perform tasks on the entire group with 

extracting data from a Level, is to perform the Set * single invocation. This concept is similar to our File 

Environment, Click on Check Out and hope for the best. In Groups. 

many instances, this may work properly, but when data The ViewLogic primary utility for creating and modifying 

exists in multiple Levels, this means possible severe data 45 e itoer type of aggregate is the Collection Editor. This tool is 

integrity risks. eas y to use > enables one to easily create Collections and 

Our integrated design control system for concurrent engi- Checkpoints as well as add and delete members. This 

neering allows a user to work with back level data (e.g. for includes creating hierarchical Collections and Checkpoints, 

fast-path ing sim fixes). When one understands this and can Despite this advanced function in the ViewLogic system, it 

compare it with the ViewLogic system, it will be appreciated 50 P 05 * 25 problems in trying to achieve BOM tracking in an 

that that system has major limitations. For example, if a environment like ours. The ViewLogic system requires the 

Version 1.5 is checked into a Level 1, and a Version 1.6 is user to check out or "own" all members tbey wish to include 

checked into Level 2, any attempt to then work with Version m tne Collection or Checkpoint. Consider the ease where an 

1.5 results in difficulty. The system default is to encourage Element Simulator wants to build a BOM containing all 

a user to work with 1.6 because it assumes the user is 55 members in a sim model. The Checkpoint would appear, 

mistakenly grabbing an obsolete version. u P° n a fi»» impression, to be a solution, however, the 

Any improvement of the ViewLogic system in connection Element Simulator must first check out all the versions of 
with extracting data from a Public Library would need to dala m lhe model - ™s immediately leads to: 
addresss permanent storage. ViewData has no method to (1) the need for the Element Simulator to have enough 
delete unwanted versions from permanent storage. Thus, in 60 AFS space in his Working Area to bold the snapshot of 
the event a user makes a mistake and promotes data to a data, something not easily addressed; and 
wrong Level, there is virtually no way to clean it up , (2) the problem of data integrity previously mentioned 
properly. Also, as the project matures, and numerous ver- because of the lack of any way for multiple versions to 
sions materialize, the Data Managers request some way to be updated simultaneously, as the designer is most 
delete the old unwanted data to reclaim space and clean up 65 likely needing to work with back-level versions of data, 
libraries. This is a problem with ViewData that needs to be Given this severe limitation, the possible power of Col- 
addressed to adopt our preferred process. lections and Checkpoints, is inadequate for a concurrent 
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engineering approach like that of our integrated design In order to make a design change, that data must be 

control system. referenced. To do this one could create an overall system 

The Viewlogic BOM handling needs to have an ability to level Library and create a schematic instantiating compo- 

expand a Checkpoint in a Library Viewer and utilize the nents from the other Teams. Upon librarying that schematic, 

icons as a visual cue to represent the BOM status. These 5 is is still difficult to work with the combined set of data, 

would be modifications that could be employed within Because of the Working Area I Release Area Union para- 

V1EWLOGIC to make this area satisfactory. digm forced by the system, a designer is unable to see all of 

We provide the ability to examine BOM operations/ the data, comprising the overall schematic, simultaneously, 

utilities. ViewLogic, in this regard, allows management of Instead, the designer must repeatedly use the Set Environ- 

Collections and Checkpoints data objects in their own right, 10 ment function to cycle through the various Working Area/ 

as they are afforded the same treatment as regular data Release Area combinations. Also, no data can be browsed in 

objects. For example, Collections and Checkpoints each can the public areas. All data has also to be checked out into the 

be Checked Out, Checked in, Promoted (with some designer's Working Area, just to look at it. Finally, working 

difficulty), and Deleted, and ViewScripts can be written to with multiple Teams is cumbersome, even though the Data 

run tasks against their members. Thus functions can be 15 Manager has complete control over establishing the Release 

performed against THE BOM without adversely affecting Areas, including their physical locations, and no Library 

the data objects being tracked by the BOM. The iconized Search mechanism is necessary, since the release area which 

representation of the BOM members in the Library View * has been designated as a Release Level consists of a com- 

allows the user to obtain the current status. plete set of pointers to the components used in the overall 

However, BOM movement through the library, like that 20 design. While making it possible to achieve the base result, 

we provide, is severely limited in the ViewLogic system, so this system is unnecessarily difficult and not conducive to 

our methods should be adopted. We do acknowledge that it concurrent engineering in an integrated design control sys- 

is possible to promote a Collection, but with difficulty. After tem. 

repeated tries, we have learned that if one accepts the One of the aspects of desirable concurrent engineering 

restriction that a user must "own" all members of a 25 would be the ability of the system to EC a released 

Checkpoint, then one is able to promote an entire BOM from component, particularly when there is the ability to release 

a Private Library into a Public Library. However, since the control if multiple ECs are being processed in parallel 

problems we discussed with respect to Level -to-Level pro- without risking that data can be intermixed between the ECs. 

motion of regular data objects, which also pertain to BOMS, The problem with the paradigm used by ViewLogic is that 

exist, there is no ability to move large BOMs easily from a 30 an EC stream is represented by a Working Area/Release 

Private Libary into a Public Library. This is a real short- Area Union. We have noted that there is a lack of visual cues 

coming of the ViewLogjc system and a compelling reason indicating the current union, and a possible promotion 

we believe of adopting our total system. mechanism with no user verification of the source and 

While design tasks can be performed non-graphically in destination. There is also no means to delete a version if it 

the ViewLogic system, it is not possible to perform BOM 35 enters the wrong storage vault, making it impossible overall 

tasks non-graphically. While ViewScripts can be written to to minimize the risk of components being released into the 

perform many functions involving Collections and wrong stream, something that must be avoided. • 

Checkpoints, they require ViewLogic ViewData to be run- With regard to building models from released data, akin 

ning in a graphical environment There are a number of to the method we discuss, the ViewLogic system provides 

disadvantages to such a system, illustrating the need for our 40 that a Release Area contains a full set of pointer to the entire 

system's ability to perform BOM tasks nongraphically. For design; however, a model builder must check out all the data 

example, if a tuning model can be created using a non- into his Working Area. This is inefficient use of AFS space, 

graphical timing tool, it should be able to interact with a especially if multiple models are to be built in parallel, since 

BOM tracker non-graphically. We provide for a command to achieve this task the user must set up multiple Working 

line environment, and it is important for a BOM tracker, as 45 Areas to use as model build areas. 

we provide (see the Section 4.6 discussion), to coexist in the View Logic allows the Data Manager to establish neces- 

same environment as the tool it is intended to work with. sary Release Areas to house "patches" to released data (i.e. 

This is not possible with the ViewLogic system. design data patches for the test floor); however, the act of 

There is a need for the problem fix management as we creating and releasing such patches often entails a designer 

provide. ViewLogic DM has no built in fix management 50 working on multiple versions of a design component in 

functions. parallel. The current ViewLogic system has many problems 

Some fix management functions with the ability of View- related to multiple check outs of the same component and 

Logic to execute specially written ViewScripts could be working with back-level data. We would refer by way of 

achieved. There was a proposal to address these concerns. contrast to the sets we use in fixing design problems in 

It must be easy in an integrated design control system to 55 multiple releases, 
make design changes for subsequent releases. When one ISO approved verification audits, which we discuss under 
tries to track an equivalent of our functions onto the View- Section 6.6, requires a DMS capable of storing results from 
Logic system design difficulties arise and the effort becomes tasks along with the proper pedigree information for the files 
difficult, even though at the highest level it is possible to used to run the tasks. It can then be enhanced to produce 
make design changes for subsequent releases. We have 60 output in a comparable format to an ISO Quality Record, 
achieved this result with unnecessary difficultly because we The current ViewLogic system offers no such mechanism, 
determined that because there is no type of Working or and our process management function and our release man- 
Engineering Level and one is forced to use the Release ager methods needs to be employed. While we have 
Levels for design iteration in the ViewLogic system. This described our preferred embodiments of our inventions, it 
requires one to perform Level -to-level promotions, which 65 will be understood that those skilled in the art, both now and 
have the problems previously mentioned. One then desig- in the future, may make various improvements and enhance- 
nates a specific one of the Release Areas as a Release Level. ments which fall within the scope of the claims which 
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follow. These claims should be construed to maintain the component data element to be developed in tandem while 

proper protection for the inventions first disclosed. using the same object name and residing in the same library 

What is claimed lis: and at the same level simultaneously. 

1. A method for computerized design automation _ . _,. r . . . . ■ 4 r „ i 

comprising 5 * A mcthod * or computerized design automation accord- 
accessing a file and database management system for 5 mg to claim 4 wherein for each said version, there is a level 

managing a plurality of projects as a design control structure denoting a degree of completeness, stability or 

system, quality control enabling said data manager a means to 

organizing data repository for each project for data establish a level structure commensurate with the goals and 

records and a control repository comprising a common o5jcctivcs of ^ ^ co mmuni t y . 

access interface and one or more databases, 1U * A ... # . , ' . . .. _ , 

.... . ., 6. A me thod for computerized design automation accord- 
said control repository commumcatmg with users of said , . 

design control system for fulfilling requests of a user *g to claun 5 wherem at leasl ^ of data are 

and the data repositories of said data management at a level chained to another level to allow data to migrate 

control system through a plurality of managers, each from one Level to the next, and wherein any or all of these 

manager performing a unique function; and 15 Levels can be designated as Entry Levels allowing data to be 

combining selected ones of said managers for supporting entered into this Entry Level from a user's Private Library; 

an computerized design automation application envi- and whereiQ there are ^so \wt\s categorized as working- 

ronment suitable for multiple users of a uscrcommu- ^ and ^ ^ [q ^ ^ fa 

mty located at workstations anywhere in the world ° , . 

accessible via a network, an intranet, extranet or via the 20 transitory, and must eventually migrate to a release level, 

internet; and while release levels provide permanent storage vaults for a 

defining for each project a control repository and one or coherent set of data. 

more data repositories to store, manage and manipulate 7. A method for computerized design automation accord- 
any data object, whereby said control repository com- m g to claim 1 further comprising, providing an architectur- 
municates with users and the data repositories in 25 a u y centralized location which does not require that the 
numerous ways to support environments ranging from ^ h icall in thc same location but kes ^ 
a small user community to a global enterprise; and , ^ J . . l l lh 
„ , , : , . c __ u the user must perceive the system in a manner by which all 

tracking all data and control information in an architec- , V , ^ , . . . . . 

rurally centralized location consisting of said data data appears to be tracked uniformly which enables the user 

repository and said control repository using a single ^ to do things like find/view all the data associated with the 

logical PFVL paradigm to identify all data in the DMS design when multiple pieces of data are in physically 

by Package, File Type, (Data l>pe), Version and Level, disparate locations. 

and wherein packages are arbitrary divisions of data, 8 A mcthod for computerized design automation accord- 
whereby all the data has some common association to ^ ^ claim j compiisisgt ^ st eps of mapping in 

2. Ame'tod for computerized design automation accord- 35 order to use the system together with other systems the 
ing to claim 1 wherein every piece of the design which is system attribute for conversion to provide the following 
associated to a mapping: 



library - Variance - Quality Level - View - CetlName - Version 
A A A /V A A 
V/ \/ \/ W \/ V 

Package - Version - Quality Level - Type - FUeName - Iteration. 



Library — Variance — Quality Level — View — Cell — 
Version has all of the data associated so that the system 
ensures every piece of data has all its PFVL attributes 
associated with it, permitting every piece of data or 
attribute of a design element in the Data Management 
System (DMS), regardless of origin or importance, to 
be tracked by its PFVL single logical association of 
every piece of the design. 

3. A method for computerized design automation accord- 
ing to claim 1 further comprising, providing that data 
management model structure capable of tracking a plurality 
of data objects governed under similar or disparate 
processes, wherein all objects are classified as part of a 
library, having one or more types, each type having one or 
more versions, and each version having one or more levels. 

4. A method for computerized design automation accord- 
ing to claim 3 wherein said library is a grouping of objects 
which all have common characteristics causing them to 
belong to the same library grouping, and wherein within a 
library, data is organized by version, wherein versions allow 
parallel evolution of the same component data element to 
coexist in the same library enabling multiple versions of a 



45 

9. A method for computerized design automation accord- 
ing to claim 1 further comprising, providing that the system 
provides working areas which serve as a private library for 
a user assigned to a team by a data manager, and to perform 

50 shared data management each team may have any number of 
Release or Integration Areas, while team members may have 
unlimited Working Areas and the system data manager can 
create release or integration areas, specify the physical 
location of the data, and rename or delete the Release or 

55 Integration Area at any time, and create virtual levels to 
define the type of structure required for concurrent engi- 
neering with multiple levels and variances, promote data 
between virtual levels and into Release Areas, and enable 
users to look at data in all Release or Integration Areas 

60 simultaneously. 

10. A method for computerized design automation accord- 
ing to claim 1 further comprising, enabling with said PFVL 
single logical paradigm attributes of non-system originated 
data to be tracked and made accessible along with system 

65 originated data with a system command. 

11. A method for computerized design automation accord- 
ing to claim 1 further comprising, enabling a user call for a 
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system function, third party tool, shell script, perl script, C execution of non-DMS tasks through the use of an Auto- 
program, or any other type of application programming reader virtual queue. 

interface from within a user system may be invoked from a 18. Amethod for computerized design automation accord- 
command line. ing to claim 1 further comprising, enabling accessible mul- 

12. A method for computerized design automation accord- 5 tiple working library levels, and means for extracting data 
ing to claim 1 further comprising, enabling a locking mecha- from a public library. 

nism which enables transfer of ownership permancndy or . »• Amemodfor^ 

temporarilyofPFVLd a ta,andallowsforanoverrideorrest t0 claun 5 ^ data <*>*"* ™ ldentlfied b * Dame and 

of the check out locks, and provides notificaUon to the ^ Amemod for computerized design automation accord- 

onginal designer or administrator in the event of check out. 10 {q ^ 19 wherei / at least ^ * of me idcn(ificd ^ 

13. Amethod for computerized design automation accord- ^ identified by a type of data object which dep j cts 
ing to claim 1 further comprising, providing that all data and ^ ob j ects ^ fii^ 

control information is tracked in an architecturally central- 21. Amethod for computerized design automation accord- 

ized location consisting of a data and control repository far t0 ^ m 19 w h erc i n a t least some of the identified data 

a project using a single logical PFVL paradigm, and wherein 15 objects are identified by a type of data object which depicts 

said system provides a dynamic Bill of Materials Tracker to the objects as files, while other data objects identified by the 

identify all the desired pieces of a design at a particular same file name exist, such that an entity of_ said data 

Library, Level and Variance to be built into a "model". management system characterized by a single name may 

14. A method for computerized design automation accord- have multiple types of data objects, simultaneously residing 
ing to claim 1 further comprising, providing that all data and 20 in multiple Levels, of multiple versions and spanning mul- 
control information is tracked in an architecturally central- tiple libraries. 

ized location consisting of a data and control repository for 22. Amethod for computerized design automation accord- 

a project using a single logical PFVL paradigm, and wherein ing to claim 6 wherein at least some of the data objects when 

said system provides Automated Library Processing the data is promoted into a release level, that Level is frozen 

whereby tools, checks and automated tasks can be launched 25 and a new release level is opened such that data always 

cither during movement of data between levels or while data migrates from the highest Working Level into the current, or 

is stable within a level and where results would be associated open, Release Level. 

to the exact data objects used in the process and retained in 23. Amethod for computerized design automation accord- 

the Control Repository. ing to claim 6 wherein at least some of the data objects when 

15. Amethod for computerized design automation accord- 30 the data is promoted into a release level, that Level is frozen 
ing to claim 1 further comprising, providing that all data and and a new release level is opened such that any working 
control information is tracked in an architecturally central- level may be promoted to from another working level, or 
ized location consisting of a data and control repository for serve as an entry level for data coming from a Private 
a project using a single logical PFVL paradigm, and wherein Library while a current Release Level can be promoted to, 
said system provides Problem Fix Management and Engi- 35 but can't be an entry point for outside data and frozen 
neering Change Tracking which would provide various Release Levels are neither entry points nor are they promot- 
utilities to ensure that fixes to problems are contained within able. 

the proper release or EC. 24. Amethod for computerized design automation accord - 

16. Amethod for computerized design automation accord- ing to claim 1 further comprising, providing that every piece 
ing to claim 1 further comprising, enabling interaction with 40 of data or attribute of a design element in the Data Man- 
said Managers of the DMS to perform tasks such as Auto- agement System (DMS), regardless of origin or importance, 
mated Library Processing, Problem Fix and EC is tracked by its PFVL single logical association of every 
management, BOM Tracking, Authority and Lock checking piece of the design. 

before, during and after the promotion of data in the DMS. 25. Amethod for computerized design automation accord- 

17. Amethod for computerized design automation accord- 45 ing to claim 1 wherein a database for the control repository 
ing to claim 1 further comprising, enabling the use of includes a multimedia database. 

Automated Library Machines in a client server environment 26. Amethod for computerized design automation accord- 

for purposes of processing promotion requests, initiating and ing to claim 1 wherein a database for the data repository 

executing Automated Library Processes, installing newly includes a multimedia database, 

created data into the DMS, performing any other functions 50 

provided by said Managers of the DMS, and permitting * * * * * 
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